fastlog name

[smichr]

I noticed that fastlog in evalf computes an approximation to log2(x).
Is there any reason not to call it fastlog2?

/c

[Ondrej Certik]

On Sat, Jul 4, 2009 at 6:52 PM, smichr<smi...@gmail.com> wrote:
>
> I noticed that fastlog in evalf computes an approximation to log2(x).
> Is there any reason not to call it  fastlog2?

Could you please be more specific? Which commands do you mean exactly?

Ondrej

[smichr]

Maybe I'm not understanding the confusion, but I mean the fastlog
method in evalf:

###
>>> from sympy import *
>>> evalf.fastlog((0, 1, 2, 1)) #i.e. log(2**2)/log(2) = 2
2
###

Since fastlog is computing the log2 approximation it makes sense to me
to call it fastlog2 rather than fastlog.

There is no test for this function. I've remedied that and also
corrected the function to compute the power of an exact power of 2
properly; previously it was off by 1 in the result. Since the mantissa
of all mpf numbers provided by mpf is suppose to be odd (according to
the documentation) then when the number is an exact power of 2, the
mantissa will be 1, the bitcount of it will also be 1 and the
approximation (exponent + bitcount) is off by 1: the bitcount should
not be added in this case.

If I can figure out how to push my changes to git I will send the
patch for this by that means. For now, I didn't change the name, I
only corrected the function and added tests.

/c

[Ondrej Certik]

On Wed, Jul 8, 2009 at 11:13 AM, smichr<smi...@gmail.com> wrote:
>
>
>
> On Jul 7, 10:38 am, Ondrej Certik <ond...@certik.cz> wrote:
>> On Sat, Jul 4, 2009 at 6:52 PM, smichr<smi...@gmail.com> wrote:
>>
>> > I noticed that fastlog in evalf computes an approximation to log2(x).
>> > Is there any reason not to call it  fastlog2?
>>
>> Could you please be more specific? Which commands do you mean exactly?
>>
>
> Maybe I'm not understanding the confusion, but I mean the fastlog
> method in evalf:
>
> ###
>>>> from sympy import *
>>>> evalf.fastlog((0, 1, 2, 1)) #i.e. log(2**2)/log(2) = 2
> 2
> ###
>
> Since fastlog is computing the log2 approximation it makes sense to me
> to call it fastlog2 rather than fastlog.
>
> There is no test for this function. I've remedied that and also
> corrected the function to compute the power of an exact power of 2
> properly; previously it was off by 1 in the result. Since the mantissa
> of all mpf numbers provided by mpf is suppose to be odd (according to
> the documentation) then when the number is an exact power of 2, the
> mantissa will be 1, the bitcount of it will also be 1 and the
> approximation (exponent + bitcount) is off by 1: the bitcount should
> not be added in this case.

Ah, yes, I think it should be called fastlog2. Fredrik, what do you think?

>
> If I can figure out how to push my changes to git I will send the
> patch for this by that means. For now, I didn't change the name, I
> only corrected the function and added tests.

Yes, I am on IRC to help you out with github. Once you get it
working, you'll see that it is easy.

Ondrej

[smichr]

On Jul 8, 10:23 pm, Ondrej Certik <ond...@certik.cz> wrote:

> Ah, yes, I think it should be called fastlog2. Fredrik, what do you think?
>

And someone who has used this should probably comment on the need to
have the sign ignored: the fastlog for both 16 and -16 would be 4 as
it is written now. *Should* the sign be ignored or should a value
error be raised or should the docstring say that the fastlog of the
absolute value of x is being computed?

/c

[Fredrik Johansson]

It's intended to compute an upper bound for the base-2 logarithm of
the absolute value of a number. This is used to determine how much
precision is required for various calculations. Whether it's exact too
high by 1 or 2 bits doesn't really matter.

It's also strictly intended as an internal function, so it probably
doesn't need much more elaborate documentation or a more precise name
(unless its present role is unclear to someone trying to understand
the internals of the evalf module).

Fredrik

[smichr]

On Jul 9, 12:18 am, Fredrik Johansson <fredrik.johans...@gmail.com>
wrote:

Then I would propose that the name be changed to _fastlog2 and the
docstring be improved to say what you have said. If that is agreeable,
I would be happy to make the changes.

Does the fact that it is intended to be internal excuse it from normal
doctests? Is there a separate level of testing for internal functions
like this or do we just assume that if the code that is dependent on
the internal-use code passes all its tests at 100% coverage that the
dependent code doesn't need tests?

/c