Are you forcing a method, such as rkf45? If that is so, then why? Could the problem be stiff?

acer

Why don't you upload a worksheet with the problematic examples in it?

acer

@TI_ET_User I'm sorry, I had it wrongly fixed in my mind that you were discussing something which did pretty much the opposite. Please ignore my earlier comments.

@TI_ET_User I'm sorry, I had it wrongly fixed in my mind that you were discussing something which did pretty much the opposite. Please ignore my earlier comments.

I have 32bit Maple 11.02 working on 64bit Windows 7 Pro. The File-Open menu item appears to work ok.

Wasn't there an update (11.02?) that allowed it to work with Vista? Is that possibly related here? But that download is not longer available via the support area of the website. Does "Check for Updates" indicate anything, if run from the menubar under the Tools menu item?

Apparently I'm not the only one who got it to work.

acer

I have 32bit Maple 11.02 working on 64bit Windows 7 Pro. The File-Open menu item appears to work ok.

Wasn't there an update (11.02?) that allowed it to work with Vista? Is that possibly related here? But that download is not longer available via the support area of the website. Does "Check for Updates" indicate anything, if run from the menubar under the Tools menu item?

Apparently I'm not the only one who got it to work.

acer

There was a time when `NextZero` wasn't so powerful (or was a little more buggy). But perhaps it's time for its functionality to be rolled into fsolve (connected to the `maxsols` option, perhaps?).

I once tried to roll it into a slightly easier-to-use procedure. The main bit about it which wasn't just candy was that it tried to handle and adjust the search range for itself.

acer

There was a time when `NextZero` wasn't so powerful (or was a little more buggy). But perhaps it's time for its functionality to be rolled into fsolve (connected to the `maxsols` option, perhaps?).

I once tried to roll it into a slightly easier-to-use procedure. The main bit about it which wasn't just candy was that it tried to handle and adjust the search range for itself.

acer

@marc005 

In your original: "What is the probability that the other is a girl?"

In your stock example: "What is the probability that stock 2 has a positive return?"

In the original, it is not given which is the boy. So the identity of the "other" is not specified. In contrast, in the stock example you specifically ask about stock 2.

Some of the results you label as OK are in fact not fully evaluated, elementwise. Note the distinction between a printed result which ostensibly shows float results and the actual content as shown by lprinting.

The `print/rtable` routine makes some of those results appear as fully evaluated, but the apparent evaluation is an artefact of the printing mechanism.

Given the earlier code, one might compare,

s:=M+K;

                       [             6                    ]
                       [1.00000002 10   1000000 sin(theta)]
                  s := [                                  ]
                       [                               12 ]
                       [  cos(theta)     1.000000000 10   ]

eval(s);

                     [             6                 5]
                     [1.00000002 10    1.231366779 10 ]
                     [                                ]
                     [                              12]
                     [  0.9923897211  1.000000000 10  ]

lprint(%);

Matrix(2, 2, {(1, 1) = 1000000.02, (1, 2) = 1000000*sin(theta), (2, 1) = cos(theta),
 (2, 2) = 0.1000000000e13}, datatype = anything, storage = rectangular,
 order = Fortran_order, shape = [])

rtable_eval(s);

                     [             6                 5]
                     [1.00000002 10    1.231366779 10 ]
                     [                                ]
                     [                              12]
                     [  0.9923897211  1.000000000 10  ]

lprint(%);

Matrix(2, 2, {(1, 1) = 1000000.02, (1, 2) = 123136.6779, (2, 1) = .9923897211,
 (2, 2) = 0.1000000000e13}, datatype = anything, storage = rectangular,
 order = Fortran_order, shape = [])

See also the rtable_eval help-page.

One of the reasons for this behaviour, I believe, is so that the entries of rtables are not evaluated when the rtable is passed as argument to a procedure call.

Note that accessing entry s[1,2] gets a float, even before `s` is hit with rtable_eval. Whether it's best to do an inplace rtable_eval on an inbound rtable argument thus can depend on whether the same entries will be accessed multiple times (from the rtable itself, within that procedure). Contrasting scenarios include accessing all entries once, vs accessing just some entries many times, etc.

One way this used to get handled with last-name-eval array-based matrix/vector was for some routines to hit the inbound argument with a full eval, as a very first step. But, otherwise, it was last-name-eval which protected the entries from full evaluation (just due to the passing in of the container as procedure argument).

acer

Some of the results you label as OK are in fact not fully evaluated, elementwise. Note the distinction between a printed result which ostensibly shows float results and the actual content as shown by lprinting.

The `print/rtable` routine makes some of those results appear as fully evaluated, but the apparent evaluation is an artefact of the printing mechanism.

Given the earlier code, one might compare,

s:=M+K;

                       [             6                    ]
                       [1.00000002 10   1000000 sin(theta)]
                  s := [                                  ]
                       [                               12 ]
                       [  cos(theta)     1.000000000 10   ]

eval(s);

                     [             6                 5]
                     [1.00000002 10    1.231366779 10 ]
                     [                                ]
                     [                              12]
                     [  0.9923897211  1.000000000 10  ]

lprint(%);

Matrix(2, 2, {(1, 1) = 1000000.02, (1, 2) = 1000000*sin(theta), (2, 1) = cos(theta),
 (2, 2) = 0.1000000000e13}, datatype = anything, storage = rectangular,
 order = Fortran_order, shape = [])

rtable_eval(s);

                     [             6                 5]
                     [1.00000002 10    1.231366779 10 ]
                     [                                ]
                     [                              12]
                     [  0.9923897211  1.000000000 10  ]

lprint(%);

Matrix(2, 2, {(1, 1) = 1000000.02, (1, 2) = 123136.6779, (2, 1) = .9923897211,
 (2, 2) = 0.1000000000e13}, datatype = anything, storage = rectangular,
 order = Fortran_order, shape = [])

See also the rtable_eval help-page.

One of the reasons for this behaviour, I believe, is so that the entries of rtables are not evaluated when the rtable is passed as argument to a procedure call.

Note that accessing entry s[1,2] gets a float, even before `s` is hit with rtable_eval. Whether it's best to do an inplace rtable_eval on an inbound rtable argument thus can depend on whether the same entries will be accessed multiple times (from the rtable itself, within that procedure). Contrasting scenarios include accessing all entries once, vs accessing just some entries many times, etc.

One way this used to get handled with last-name-eval array-based matrix/vector was for some routines to hit the inbound argument with a full eval, as a very first step. But, otherwise, it was last-name-eval which protected the entries from full evaluation (just due to the passing in of the container as procedure argument).

acer

@TI_ET_User The way I understand it (and apologies if I conveyed my understanding poorly) was that calls to queryInterrupt can be placed in one's OpenMaple example (driver) code. Have you tried inserting such at a suitable place inside, say, omexample.c?

@TI_ET_User The way I understand it (and apologies if I conveyed my understanding poorly) was that calls to queryInterrupt can be placed in one's OpenMaple example (driver) code. Have you tried inserting such at a suitable place inside, say, omexample.c?

You might also find this of some interest. (Sorry for not mentioning it before... I'd forgotten about it.)

acer

You might also find this of some interest. (Sorry for not mentioning it before... I'd forgotten about it.)

acer