Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
on numval, rounded;
logb(2^(-101),2); %not evaluated
logb(3^(-33),3); %not evaluated
log(2^(-101))/log(2) works though.
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.
Thanks for prompt answer, I'm using Reduce (Free CSL version), 31-Mar-12
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)
Now I'm testing with trunk. With
the behavior is as described above.
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.
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...
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.
I updated trunk and everything works nicely.
@Rainer, Arthur: thanks for the fast analysis and fix!