sand15

735 Reputation

11 Badges

9 years, 93 days

MaplePrimes Activity


These are replies submitted by sand15

@dharr 

I didn't know this tip to avoid the syntax error, very valuable information.
Good luck for the continuation.

@dharr 

Hi,
You missed one: the loop starts with m=2 and thus dff(..., eta$(m-2)) is not correct :-)

@acer 

I suspect the OP might have had something like this in mind

k  := sqrt(sigma^2-`V__+`):
kt := convert(taylor(k, `r__∝` = 100, 30), polynom):
int(kt, `r__∝`)

 

If you have a true problem to solve, why not use  GraphTheory:-TravelingSalesman instead of ChatGPT?
Unless it was just to see what ChatGPT is capable of?

@Carl Love 

It's a real pity 2D mode is so permissive; such a typing error would be immediately noticed in 1D mode.
Thank goodness  plots:-dis play(...)  produces an error in 2D mode.

Thank you @acer

@acer 

Pretty, I vote up.

Is it possible, as with animate, to change the numer of frames per second when you click on the animation right triangle?

@Carl Love 

That is indeed a good explanation and, although I am still an amateur at Maple, I do believe that this package would benefit from a rewrite.

@Nicole Sharp 

Thanks for the information Nicole.
I really appreciate your last site which brings back old memories.

@Carl Love 

Thank you Carl for your analysis.

@Nicole Sharp 

Thanks for your return.
I had already noticed some discrepencies between Maple 2015/ScientificConstants and this reference NIST
 (which is quite understandable as the nominal values and tolerances are regularly adjusted to account for new measurements).

You also write that some contants, Planck's for instance, do not have uncertainty, to which I agree. I have always found curious Maple 2015/ScientificConstants saying the opposite (I don't know if this has been updated in more recent versions [upu seem to say it hasn't]). Maybe by the time this package has been developed the conventions about which are the "exact constants" weren't the same as today?

@Carl Love 

I agree that constructions like mine must not contain spaces, which makes them less easy to write and read.
I rhought you would have point out that something like

t := `#mover(......,mathcolor="red")`

doesn't modify the color of t and that the modifier mathcolor has to be applied to each mo/mi/mn.
This seems to be a great advantage to you construction.

For instance you can do this and get a red title

T:= Typesetting:
t := T:-mover(T:-msub(T:-mi("u"), T:-mn("1")), T:-mo("→"), 'mathcolor'= 'red');
plots:-textplot(
    [1, 2, t], title=t
);

But my doing this returns a black title

t := `#mover(msub(mi("u"),mn("1")),mo("→"))`:
plots:-textplot(
    [1,2, t], color=red, title=t
)

BTW:  mathcolor seems to be deprecated

@Carl Love 

What is the advantage to use Typesetting?
Why not this:

t := `#mover(msub(mi("u"),mn("1")),mo("→"))`:
plots:-textplot(
    [1,2, t],
    'align'= {'above', 'right'}, 'font'= ["ARIAL", 'BOLD', 16], color=red
)

@Preben Alsholm 

My mistake, I guess I have to change my spectacles

@Carl Love 

Thanks Carl.

But it seems that test and `test` do not mean exactly the same thing here:
 

restart

test1 := 1: test2 := 2:

select(type, {anames()}, suffixed(test));

{test1, test2}

(1)

select(type, {anames()}, suffixed('test'));

{test1, test2}

(2)


But if test is assigned, suffixed(test) generates an error while suffixed('test') doesn't

test := 0: test1 := 1: test2 := 2:

select(type, {anames()}, suffixed(test));

Error, (in type/suffixed) expecting a 1st argument of type {string, symbol, list(symbol, string), set(symbol, string)}

 

select(type, {anames()}, suffixed('test'));

{test, test1, test2}

(3)

 


 

Download hum.mw

1 2 3 4 5 6 7 Last Page 1 of 23