Yes, the presence of a float amongst numeric values of the integration range will trigger `int` to do numeric integration (quadrature) as if it had been called like evalf(Int(...)). See the 5th bullet point in the Description section of the help page for the int command.

The presence of a float in the integrand, but not in the range, is not sufficient to trigger this behaviour.

By the way, the first result you show is the inaccurate one. Basically, the result of symbolic integration done for your first `int` call is a formula that presents more numeric difficulty than does the original integrand. I believe that `int` does essentially the same computation whether I used 1/2 or 0.5 below for the third argument of dgig (in the case of exact, non-float values in the range).

restart:
dgig := proc(psi, chi, lambda, t)
(psi/chi)^(lambda/2)*t^(lambda - 1)*exp(-(psi*t+chi/t)/2)/\
(2*BesselK(lambda,sqrt(chi*p\si))):
end: ## End of dgig
res:=int(dgig(60, 60, 1/2, t), t = 0..1);
1 / (1/2) (1/2)\ 1 1
foo := - exp(120) erf\2 2 15 / - - exp(120) + -
2 2 2

So, `res` is the sum of three things: a very large positive quantity, a very large negative quantity, and 1/2. Unless a sufficient number of digits when adding the first of those two quantities then then roundoff error can cause that pair of values to cancel inaccurately to zero.

(1/2)*exp(120)*erf(2*2^(1/2)*15^(1/2));
1 / (1/2) (1/2)\
- exp(120) erf\2 2 15 /
2
evalf[100](%): part1:=evalf[10](%);
51
part1 := 6.520904392 10
-(1/2)*exp(120);
1
- - exp(120)
2
evalf[100](%): part2:=evalf[10](%);
51
part2 := -6.520904392 10
part1+part2; # inaccurate!
0.

(By the way, if Maple had first added together the first and third of the addends in the sum, then I'd expect to see catastrophic cancellation wipe out the 1/2, ending up with zero as the inaccurate answer instead of 0.5.

Increasing the working precision, an accurate result emerges:

restart:
dgig := proc(psi, chi, lambda, t)
(psi/chi)^(lambda/2)*t^(lambda - 1)*exp(-(psi*t+chi/t)/2)/\
(2*BesselK(lambda,sqrt(chi*p\si))):
end: ## End of dgig
res:=int(dgig(60, 60, 1/2, t), t = 0..1);
1 / (1/2) (1/2)\ 1 1
res := - exp(120) erf\2 2 15 / - - exp(120) + -
2 2 2
evalf[40](res): evalf[10](%);
0.5000000000
evalf[55](res): evalf[10](%);
0.4750000000
evalf[56](res): evalf[10](%);
0.4745000000
evalf[57](res): evalf[10](%);
0.4743500000
evalf[63](res): evalf[10](%);
0.4743543708

The integrand, on the other hand, does not suffer from these issues, and function evaluation (eg. plotting) or numeric integration succeeds easily even at less than double-precision.

> restart:
> dgig := proc(psi, chi, lambda, t)
> (psi/chi)^(lambda/2)*t^(lambda - 1)*exp(-(psi*t+chi/t)/2)/\
> (2*BesselK(lambda,sqrt(chi*psi))):
> end: ## End of dgig
> dgig(60, 60, 0.5, t): lprint(%);
0.3529023946e27*exp(-30*t-30/t)/t^.5
> evalf(Int(t->evalf[11](0.3529023946e27*exp(-30*t-30/t)/t^.5), 0..1.0));
0.4743543709