acer

32333 Reputation

29 Badges

19 years, 318 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by acer

I believe that it refers to Madam d'Urfe's use of a polyalphabetic (or Vignere) cipher, used to encrypt her document which explained the secret of transmuting base metals into gold.

Supposedly, the key was NABUCODONOSOR. That is Italian for Nebuchadnezzar, a name that I did not expect to write on mapleprimes.

acer

I believe that it refers to Madam d'Urfe's use of a polyalphabetic (or Vignere) cipher, used to encrypt her document which explained the secret of transmuting base metals into gold.

Supposedly, the key was NABUCODONOSOR. That is Italian for Nebuchadnezzar, a name that I did not expect to write on mapleprimes.

acer

It's difficult, without an example, to know what might be happening here. The problem could be how Maple's handling the example, or something to do with the fact that it's getting passed in from Matlab.

Could you post the example, or upload it here as a file?

acer

It's difficult, without an example, to know what might be happening here. The problem could be how Maple's handling the example, or something to do with the fact that it's getting passed in from Matlab.

Could you post the example, or upload it here as a file?

acer

I see, you were using the fact that sets "uniquify" their members and get rids of duplicates. You might use the {} as you had before, to eliminate duplicates. Then, before sorting, convert T to a list, ie. T:=convert(T,list);

Not to throw you off track, as you've been making progress, but I might have chosen a Maple table rather than a list of lists as structure to represent a roll. It's not a big deal -- you should be able to succeed with your own way.

acer

I see, you were using the fact that sets "uniquify" their members and get rids of duplicates. You might use the {} as you had before, to eliminate duplicates. Then, before sorting, convert T to a list, ie. T:=convert(T,list);

Not to throw you off track, as you've been making progress, but I might have chosen a Maple table rather than a list of lists as structure to represent a roll. It's not a big deal -- you should be able to succeed with your own way.

acer

The first thing I tried was D, naturally. But for some reason, I just forgot about VectorCalculus.

Now it makes me wonder, couldn't :-D sensibly apply VectorCalculus:-D to Vector-valued functions? Right now it just returns unevaluated, and even evalf (fdiff) doesn't do anything with it. Would it necessarily slow :-D down too much, to check?

acer

The first thing I tried was D, naturally. But for some reason, I just forgot about VectorCalculus.

Now it makes me wonder, couldn't :-D sensibly apply VectorCalculus:-D to Vector-valued functions? Right now it just returns unevaluated, and even evalf (fdiff) doesn't do anything with it. Would it necessarily slow :-D down too much, to check?

acer

I suspect that what was mostly needed, for the usenet poster's request, was to overload (and possibly redefine) mvMultiply.

The bit about redefining :-`*` was perhaps not necessary at all. I thought that I had not been able to get it all to work satisfactorily without the :-`*` redefinition. But I could well have made a mistake.

But now I reread the bit about how overloaded operators may not get used in routines saved to (and read in from) a Library archive. So perhaps it was necessary, in order to get that part of it to work. Maybe someone else can try, with a simple example using a saved, non-builtin Library routine.

The 4th bullet point on the ?overload help-page indicates that the previous binding will be used as a fall-through. The ?use help-page also lists operators that can be rebound, with some extra discussion.

The introduction of type `*` was likely only necessary on account redefining :-`*`.

acer

On the help-page ?evalf,Int you can see that the tolerance can be set independently from the working precision.

evalf(Int(...)) takes an optional argument of the form 'epsilon'=value to specify the requested tolerance. I believe that it is relative tolerance, for most of its methods. And it takes an optional argument of the (lowercase) form 'digits'=value to specify the working precision.

Now, normally evalf/Int will set epsilon as something like one half ulp, according to Digits (or the digits argument). That can sometimes present numerical difficulties. But you can keep the epsilon fixed (using the optional argument) to as low as is acceptable, and then crank up the working precision (using the optional argument) as high as you wish. In this way you might gain some assurance that, say, any bad numerical conditioning of the problem has been overcome and that the estimated error estimates are actually valid (while being below the requested error tolerance).

Setting infolevel[`evalf/int`]:=1 should provide some additonal printed outout about, say, the estimated error levels.

acer

On the help-page ?evalf,Int you can see that the tolerance can be set independently from the working precision.

evalf(Int(...)) takes an optional argument of the form 'epsilon'=value to specify the requested tolerance. I believe that it is relative tolerance, for most of its methods. And it takes an optional argument of the (lowercase) form 'digits'=value to specify the working precision.

Now, normally evalf/Int will set epsilon as something like one half ulp, according to Digits (or the digits argument). That can sometimes present numerical difficulties. But you can keep the epsilon fixed (using the optional argument) to as low as is acceptable, and then crank up the working precision (using the optional argument) as high as you wish. In this way you might gain some assurance that, say, any bad numerical conditioning of the problem has been overcome and that the estimated error estimates are actually valid (while being below the requested error tolerance).

Setting infolevel[`evalf/int`]:=1 should provide some additonal printed outout about, say, the estimated error levels.

acer

I mentioned that T should be a list, not a set, for that particular `sort` idea.

Note the use of [ ] brackets, rather than { } brackets,

> T:= [op(map(x->[x,Occurrences('x',rolls)],rolls))];

                  T:= [[1, 1], [4, 2], [5, 2]]

acer

I mentioned that T should be a list, not a set, for that particular `sort` idea.

Note the use of [ ] brackets, rather than { } brackets,

> T:= [op(map(x->[x,Occurrences('x',rolls)],rolls))];

                  T:= [[1, 1], [4, 2], [5, 2]]

acer

Good job so far. Now you can use the `sort` routine (on T as a list rather than a set).

It works by sorting according to size of the second element

>  T:=[[1, 1], [4, 1], [5, 1], [6, 2]];
                     T := [[1, 1], [4, 1], [5, 1], [6, 2]]
 
> sort(T,(a,b)->a[2]>b[2]);
                       [[6, 2], [5, 1], [4, 1], [1, 1]]

There are more efficient and involved ways. But this should work for your task, and is simple.

acer

Good job so far. Now you can use the `sort` routine (on T as a list rather than a set).

It works by sorting according to size of the second element

>  T:=[[1, 1], [4, 1], [5, 1], [6, 2]];
                     T := [[1, 1], [4, 1], [5, 1], [6, 2]]
 
> sort(T,(a,b)->a[2]>b[2]);
                       [[6, 2], [5, 1], [4, 1], [1, 1]]

There are more efficient and involved ways. But this should work for your task, and is simple.

acer

First 513 514 515 516 517 518 519 Last Page 515 of 591