floor(integer)

[Eric Reyssat-2]

Hi,

does anybody know how the floor function behaves when its argument is an
integer which is not obviously integer ?
for instance
floor(log(5)/log(2))   ==> 2 (correct)
but
floor(log(4)/log(2))   ==> floor(log(4)/log(2))  (I would expect 2 or 1)

The documentation says the argument is bfoat-evaluated at first. This of
course could give a wrong answer (if log(4)/log(2)=1.999 instead of 2)
but I didn't expect such unevaluated answer. Did I miss something ?

A numerical evaluation gives what I expect
ev(floor(log(4)/log(2)),numer);    ==> 2


Eric Reyssat
_______________________________________________
Maxima mailing list
Maxima@...
http://www.math.utexas.edu/mailman/listinfo/maxima

[Barton Willis]

maxima-bounces@... wrote on 11/20/2006 11:55:32 AM:

> Hi,
>
> does anybody know how the floor function behaves when its argument is an

> integer which is not obviously integer ?
> for instance
> floor(log(5)/log(2))   ==> 2 (correct)
> but
> floor(log(4)/log(2))   ==> floor(log(4)/log(2))  (I would expect 2 or 1)
>
> The documentation says the argument is bfoat-evaluated at first. This of

> course could give a wrong answer (if log(4)/log(2)=1.999 instead of 2)
> but I didn't expect such unevaluated answer. Did I miss something ?

Given an argument that is a constant, the floor function evaluates the
argument using three different values for fpprec. If all of these values
basically agree *and* if all of these three values are reasonably far away
from an integer, floor returns an integer; otherwise floor returns a noun
form. For floor(log(4)/log(2)), floor decides that the big float values
of log(4)/log(2) are all too close to an integer to safely determine the
output, so floor (wisely, I think ;)) returns a noun form. Try something
like

  for i : 10 thru 20 do (fpprec : i, print(i,is(rationalize(2 <
log(4.0b0)/log(2.0)))));

I wrote the current floor and ceiling functions. I wanted them to return
noun forms more often then wrong values. I still think this is the best
approach.
You could do something like

(%i70) radcan(floor(log(4)/log(2)));
(%o70) 2

Maybe radcan isn't quite the right function, I can't think right now.

Barton

_______________________________________________
Maxima mailing list
Maxima@...
http://www.math.utexas.edu/mailman/listinfo/maxima

[Richard Fateman]

I believe that the commercial macsyma includes a program by Bill Gosper to determine the values of inequalities by a more principled method involving computing how many bits of precision are necessary to determine the sign of an algebraic expression (or the direction of an inequality)
and then computing the result. At least when possible.

 

RJF



Barton Willis wrote:

maxima-bounces@... wrote on 11/20/2006 11:55:32 AM:

  

Hi,

does anybody know how the floor function behaves when its argument is an 
    

integer which is not obviously integer ?
for instance
floor(log(5)/log(2))   ==> 2 (correct)
but
floor(log(4)/log(2))   ==> floor(log(4)/log(2))  (I would expect 2 or 1)

The documentation says the argument is bfoat-evaluated at first. This of 
    

course could give a wrong answer (if log(4)/log(2)=1.999 instead of 2) 
but I didn't expect such unevaluated answer. Did I miss something ?
    

Given an argument that is a constant, the floor function evaluates the 
argument using three different values for fpprec. If all of these values
basically agree *and* if all of these three values are reasonably far away
from an integer, floor returns an integer; otherwise floor returns a noun
form. For floor(log(4)/log(2)), floor decides that the big float values
of log(4)/log(2) are all too close to an integer to safely determine the
output, so floor (wisely, I think ;)) returns a noun form. Try something 
like

  for i : 10 thru 20 do (fpprec : i, print(i,is(rationalize(2 < 
log(4.0b0)/log(2.0)))));

I wrote the current floor and ceiling functions. I wanted them to return
noun forms more often then wrong values. I still think this is the best 
approach.
You could do something like

(%i70) radcan(floor(log(4)/log(2)));
(%o70) 2

Maybe radcan isn't quite the right function, I can't think right now.

Barton

_______________________________________________
Maxima mailing list
Maxima@...
http://www.math.utexas.edu/mailman/listinfo/maxima
  

_______________________________________________
Maxima mailing list
Maxima@...
http://www.math.utexas.edu/mailman/listinfo/maxima

[Barton Willis]

axima-bounces@... wrote on 11/20/2006 12:28:40 PM:

> I believe that the commercial macsyma includes a program by Bill
> Gosper to determine the values of inequalities by a more principled
> method involving computing how many bits of precision are necessary
> to determine the sign of an algebraic expression (or the direction
> of an inequality)
> and then computing the result. At least when possible.

Although my method is sophomoric, I don't recall it ever giving
an answer that is just plain wrong (sometimes it returns a noun
form when it shouldn't, but not wrong). It's a shame that Bill Gosper's
code is effectively lost---I think that duplicating it would be a
great deal of work. If anybody would like to try, that would be
great. But I think other fixes (say fix sign for linear inequalities)
have a much higher priority.

Barton
_______________________________________________
Maxima mailing list
Maxima@...
http://www.math.utexas.edu/mailman/listinfo/maxima