#36 logb doesn't give a number for small numbers

[Zbynek Konecny]

try

on numval, rounded;
logb(2^(-100),2); %ok
logb(2^(-101),2); %not evaluated
logb(3^(-33),3); %not evaluated

log(2^(-101))/log(2) works though.

[Rainer Schöpf]

I tried your input in the latest version from svn, and it works.

Could you please indicate which version of Reduce you are using, ie. platform PSL/CSL, the date displayed when Reduce is started.

Rainer

[Zbynek Konecny]

Thanks for prompt answer, I'm using Reduce (Free CSL version), 31-Mar-12

[Rainer Schöpf]

I tested on both CSL and PSL from the latest svn trunk, on an Ubuntu Linux on x86-64 processor.

Could you please try to rebuild from the latest sources? (Processor and operating system shouldn't make a difference, but you never know until you try)

Thanks, Rainer

[Zbynek Konecny]

Now I'm testing with trunk. With
on roundbf;
the behavior is as described above.
With
off roundbf;
logb(2^(-1022),2); %gives number
logb(2^(-1023),2); %switches roundbf to on and does not give a number

The March version did the same thing, I forgot to mention that I used some inputs that switched roundbf.

Thanks,
Zbynek

[Arthur Norman]

While I do not yet have a solution, I believe that the change of behaviour related to the value of !:bprec!: and its treatment in greaterp!: in arith/smlbflot.red. And I suspect that the code there is (incorrectly!) viewing 2^(-100) as so close to zero to be treatable as equal to it...
Arthur

[Rainer Schöpf]

I agee with Arthur. Fortunately, there are only very few places in the source code where greaterp!: is used for comparison to zero, namely in arith/rdelem.red and specfn/sfbern.red.

Bug fix and regression test checked in.

Rainer

[Zbynek Konecny]

I updated trunk and everything works nicely.

@Rainer, Arthur: thanks for the fast analysis and fix!