## 13653 Reputation

19 years, 288 days

## The effect of _EnvLinalg95...

@sursumCorda My guess is the opposite: With _EnvLinalg95:=true some use may be made of the old linalg package in computing output from some LinearAlgebra commands.

How did you come to know about the existence of _EnvLinalg95?
I never heard of it before.

## A wild guess...

Could _EnvLinalg95 have something to do with the old linalg package? The number 95 could refer to the year 1995.
So setting _EnvLinalg95:=true could mean that you now work in an environment where use is made of that old and deprecated package.
If you try with(linalg);  you get the contents. There doesn't seem to be any command like EigenConditionNumbers, thus the LinearAlgebra version is used.

## Indeed method=Parts work...

@ I tried method=Parts on both examples in Maple 2023.2 as mentioned by Igor Proskurin.
Specifically:

```res:=int(integrand,t,method=Parts):
res2:=int(integrand2,t,method=Parts):
simplify(integrand-diff(res,t)); # 0
simplify(integrand2-diff(res2,t)); # 0
```

## Points remained...

@Preben Alsholm The seven points remained as I feared.
Any reference to the question seems to be gone, which is a good.

@C_R I thought of that, but I was afraid that the undeserved points would remain.
It is worth trying though. If the points remain then that exposes a flaw in MaplePrimes.
I can live with 7 undeserved points.

## Tried...

As seen (until tomorrow)  in my answer to my own test question "How to determine if 2+2 = 4?" I'm able to select my own answer as the best answer. It ought not be possible in my view! I received 7 points. Nobody is able to give himself 5 points by giving the answer a vote up. Why should it be different for selecting the best answer?
I shall remove my question and my 7 points tommow morning (Sunday).

## Thanks...

@Carl Love Thanks, I shall remove the whole thing, including the points, tomorrow morning.

## Will this be removed?...

@Preben Alsholm I prefer that it is removed!
(And the 7 points I received are deducted as well!)

## Test...

I shall do a test question and quickly answer it myself to see what happens.

## Manipulation...

Surely Maple isn't using textbook methods from typical ode courses in college.
I'm not surprised that different methods lead to different looking results, where both are correct.
The lengthy one, which actually has an inert integral, can be made to look like your simple one:

```val:=value(y_general_direct_method):
sol:=simplify(evalc(val)) assuming x>0;
length(sol);       # 769
length(y_general); # 643
odetest(sol,ode);  #0

```

## Using foldr works...

I realize that the following "solution" is besides the point, but here it is:

```foldr(subsop,expr,1=a,2=b,3=c,4=d);
foldr(subsop,expr,4=d,3=c,2=b,1=a);
foldr(subsop,expr,2=b,3=c,4=d,1=a);
## All return a*b*c*d```

foldr also works in the new example by C_R:

```foldr(subsop,expr,1=a,2=b);
## a*b*(46*r0 - 41*Delta_r)*r0^5```

This appears to be an "ancient" bug: Maple 12 as well as Maple 2021, 2022 has it too.
The problem is the real number (-1) as the first operand. Same problem with any other concrete real number like 7. No problem with sqrt(2).

## Converting to software floats...

@nm It appears that the different addresses problem is due to using hardware floats.
So here is another way out using your original example:

```restart;
ode2:=2*y(t)+t*diff(y(t),t) = t^2-t+1;
p:=DEtools:-DEplot(ode2,y(t),t=0..3.5,y=0..3,
linecolor = red,
arrowsize ='magnitude',
numpoints = 200 ,
axes = boxed,color = ('magnitude[legacy]')):
###############################################
p0:=Array(1 .. 3,1 .. 2,{(1, 1) = HFloat(undefined), (1, 2) = HFloat(undefined), (2
, 1) = HFloat(undefined), (2, 2) = HFloat(undefined), (3, 1) = HFloat(undefined
), (3, 2) = HFloat(undefined)},datatype = float[8],order = C_order);
####
has(p0,HFloat(undefined));
p1:=op([1,2],p);
has(p1,HFloat(undefined));
################ Now convert to software floats:
p0S:=convert~(p0,'sfloat');
p1S:=convert~(p1,'sfloat');
has(p0S,Float(undefined));# true
has(p1S,Float(undefined)); # true
```

## arrowsize ='magnitude'...

Just an observation: If you remove the option arrowsize ='magnitude' then you don't get an empty plot, although there are undefined parts.

## A procedure...

@nm Whether this is a bug or only a weakness I can't tell.
Here is a procedure which at least handles the present situation:

```restart;
ode1:=2*y(t)+t*diff(y(t),t) = t^2-t+1;
p1:=DEtools:-DEplot(ode1,y(t),t=0..3.5,y=0..3):

ode3:=3*y(t)+diff(y(t),t) = t^2-t+1;
p3:=DEtools:-DEplot(ode3,y(t),t=0..3.5,y=0..3):
p3;
#####################################
HasUndefined:=proc(p) local L,q,res;
L:=select(type,[op([1,1..-1],p)],'hfarray');
##########
q:=proc(a::hfarray) local ar:=type~(a,realcons);
if convert(ar,set)={true} then true else false end if
end proc;
##########
res:=remove(q,L);
if res<>[] then true else false end if
end proc:
HasUndefined(p1); #true
HasUndefined(p3); #false
```

## A way around...

This seems to be a way around the problem: Fishing out the undefined:

```###Continuing with A0, A1, and A2:
evalb(op(2,indets(A1,hfloat)[1])=undefined);
evalb(op(2,indets(A2,hfloat)[1])=undefined);
evalb(op(2,indets(A0,hfloat)[1])=undefined);
# All 3 return true.```
 First 7 8 9 10 11 12 13 Last Page 9 of 229
﻿