sand15

787 Reputation

11 Badges

9 years, 150 days

MaplePrimes Activity


These are replies submitted by sand15

@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

@Preben Alsholm 

Thanks, I understand now.

@vv 

I don't understand your answer.
I know the difference between sum and add, but using sum in the definition of S works perfectly well in Maple 2015 (the version I used in my comment) and Maple 2021 (I checked it right now).

So why did you make this answer? Does S := (N, x) -> sum(...) no longer work in Maple 2023?

@acer 

Great, than you very much

@Carl Love 

"It's obvious (to me at least) ..."
I guess I have to get rid of my by crystal ball and buy a new one :-)

@acer 

Thanks, it's clear now

@acer 

I vote up... even if I do not understand what really happens.
In

Int(unapply(eval(op(1,ig),y=Y),x), rhs(op(2,ig)))

what makes Maple recognize that the integration has to be done with respect of x and not Y?

Why does the following lines generate an error?

F := Y->evalf(Int(unapply(eval(op(1,ig),y=Y),x), x=rhs(op(2,ig)))):
CodeTools:-Usage(plot(F, 0 .. 0.25, size = [400, 300]));

@Scot Gould 

F...g great!
I vote up.

@nm 

Thanks, I will try to build a simple example that presents the issue.

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