What do you say to log2 to Math module?


#1

Hi list.

I’m using ruby for my research purpose, and as everyone knows
computer science is all about log function whose base is 2.

Unfortunately, Math module does not contain log2 though it has
log10. What do you think about adding log2 to Math?

Yes, I know that adding log2 is way so simple because I can
open Math module and add log2 method, but I’ve had to that ALWAYS.

Sincerely,
Minkoo S.


#2

Minkoo S. wrote:

I’m using ruby for my research purpose, and as everyone knows
computer science is all about log function whose base is 2.

Unfortunately, Math module does not contain log2 though it has
log10. What do you think about adding log2 to Math?

Yes, I know that adding log2 is way so simple because I can
open Math module and add log2 method, but I’ve had to that ALWAYS.

I say yes to log2.

Cheers,
Dave


#3

On May 3, 2006, at 5:47 PM, Dave B. wrote:

I say yes to log2.

Cheers,
Dave

Why not just redefine Math.log(numeric) to be Math.log(numeric, base
= Math::E)
It won’t even break existing code, and is slightly less typing than
log(numeric)/log(base)


#4

To whom should I have to correspond to submit request for a feature?
Is there some kind of process or rule that I have to conform to?

Sincerely,
Minkoo S.


#5

On May 4, 2006, at 4:12 PM, Minkoo S. wrote:

To whom should I have to correspond to submit request for a feature?
Is there some kind of process or rule that I have to conform to?

Sincerely,
Minkoo S.

http://www.rcrchive.net/


#6

In article
removed_email_address@domain.invalid,
“Minkoo S.” removed_email_address@domain.invalid writes:

To whom should I have to correspond to submit request for a feature?
Is there some kind of process or rule that I have to conform to?

ruby-core or RCR.

I guess it is easy to persuade matz because log2 is defined
by C99 and POSIX.


#7

Hi,

In message “Re: What do you say to log2 to Math module?”
on Fri, 5 May 2006 09:34:44 +0900, Tanaka A. removed_email_address@domain.invalid
writes:

|I guess it is easy to persuade matz because log2 is defined
|by C99 and POSIX.

Right. And I did it last night. Although gcc gives me warning
“incompatible implicit declaration of built-in function ‘log2’” unless
I specify -std=c99.

						matz.

#8

On May 4, 2006, at 9:46 PM, Yukihiro M. wrote:

“incompatible implicit declaration of built-in function ‘log2’” unless
I specify -std=c99.

  					matz.

Off on a tangent here, but is -std=c99 ok with ruby’s K&R style C?


#9

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Minkoo S. wrote:

I’m using ruby for my research purpose, and as everyone knows
computer science is all about log function whose base is 2.

Unfortunately, Math module does not contain log2 though it has
log10. What do you think about adding log2 to Math?

A few weeks ago, someone in the #ruby-lang channel on
irc.freenode.net showed me an easy way of doing log2 in Ruby:

integer.to_s(2).length

irb(main):011:0> 3.to_s(2)
=> “11”
irb(main):012:0> 3.to_s(2).length
=> 2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEWsa/mV9O7RYnKMcRAhFrAJ9OIW1Dm61kAOBePYFYSoSLjwSQWACgoXrS
+1VQeu8l5EhS7dA17sLI/ks=
=f/Uy
-----END PGP SIGNATURE-----


#10

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Suraj N. Kurapati wrote:

irc.freenode.net showed me an easy way of doing log2 in Ruby:
Correction: this calculates the ceiling of log2.

For my purposes, it was useful when determining how many bits are
necessary to represent an unsigned integer.

integer.to_s(2).length

irb(main):011:0> 3.to_s(2)
=> “11”
irb(main):012:0> 3.to_s(2).length
=> 2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEWsh8mV9O7RYnKMcRAgjoAJ9Siy6nNiEMZupragmbDEg+ouqqTQCeLEOx
6GSZwDgEpU/O6DyAL6vLn7c=
=9Tld
-----END PGP SIGNATURE-----


#11

Thank you for your time and effort!!

Sincerely,
Minkoo S.


#12

Am I missing something here? In any programming language, define the
constant

Multiplier = 1.0/logtoanybase(2)

Then

log2(x) = Multiplier*logtoanybase(x)

You have to compute the Multiplier once. My guess is that most
implementations of other languages compute logs to only one base,
probably the natural (base e) log, and compute logs to all other bases
by doing this multiplication every time you call them – or worse, not
pre-computing the Multiplier and doing a divide every time, which takes
longer and is less accurate.

Minkoo S. wrote:

Sincerely,
Minkoo S.


M. Edward (Ed) Borasky

http://linuxcapacityplanning.com


#13

On May 6, 2006, at 2:39 PM, M. Edward (Ed) Borasky wrote:

implementations of other languages compute logs to only one base,
probably the natural (base e) log, and compute logs to all other bases
by doing this multiplication every time you call them – or worse, not
pre-computing the Multiplier and doing a divide every time, which
takes
longer and is less accurate.

I’m sure they do, he would just like to avoid typing

module Math
Log2Multiplier = 1.0 / self.log(2.0)
def self.log2(x)
self.log(x) * Log2Multiplier
end
end

everytime he writes a new program


#14

Hi,

In message “Re: What do you say to log2 to Math module?”
on Fri, 5 May 2006 11:12:38 +0900, Logan C.
removed_email_address@domain.invalid writes:

|> Right. And I did it last night. Although gcc gives me warning
|> “incompatible implicit declaration of built-in function ‘log2’” unless
|> I specify -std=c99.

|Off on a tangent here, but is -std=c99 ok with ruby’s K&R style C?

No. That’s the problem.

						matz.

#15

On 06/05/06, M. Edward (Ed) Borasky removed_email_address@domain.invalid wrote:
[…]

You have to compute the Multiplier once. My guess is that most
implementations of other languages compute logs to only one base,
probably the natural (base e) log, and compute logs to all other bases
by doing this multiplication every time you call them – or worse, not
pre-computing the Multiplier and doing a divide every time, which takes
longer and is less accurate.
[…]

Actually, no.

Most programming languages do not implement their own log functions,
they use those provided in libmath. The latter provides two distinct
functions for natural and base-two logs.
On intel processors, the FPU directly provides the instructions FYL2X
and FYL2XP1 [1] for logarithms, and, in case you’re wondering, L2
stands for log2: the two instructions compute y * log2(x) and y *
log2(x+1), respectively, with x at the top of the FPU stack and y just
below.

When computing log2(x) you just push 1 and x on the FPU stack then do an
FYL2X.
When computing log(x) you push log(2)=1/(log2(e)) (with the dedicated
instruction FLDLN2) and x on the FPU stack then do an FYL2X.
For an arbitrary base you have to pre-compute 1/(log2(x)) with FYL2X
as described above.

If your processor does not handle logarithms natively, libmath
implementations usually have two different implementations for log and
log2 to minimize rounding errors. See for instance
sysdeps/ieee754/dbl-64/e_log2.c and sysdeps/ieee754/dbl-64/e_log.c in
the GNU C library version 2.4 [2]. In sysdeps/i386/fpu/ you’ll see the
Intel-specific implementations.

Ciao,
Stefano

[1] http://www.intel.com/design/Pentium4/manuals/253666.htm
[2] http://www.gnu.org/software/libc/libc.html


#16

Hi,

I’ve been using OpenSSL::Cipher to try and talk to an IPSec
implementation
and ran into something weird. I read what documentation there is and
consulted google and the archives with little success. I’ll try and
explain
via irb.

irb(main):669:0> ctext
=>
“Y\322\325T8As\226\360\t\335\3329\257\366\263WW\024<A\2632vg\026\a\353G\217
237\004”

That is what I receive on the wire

irb(main):670:0> plain
=>
“\010\000\000\f\001\000\000\000\254\020#\200\000\000\000\024\254\2749\350\22
6t\235k\203\375]\200\226\316\210@”

That is the correct decryption, once I trick the Cipher module.

irb(main):671:0> key
=> “:I.\354\246\022O\e”
irb(main):672:0> iv
=> “\234W\211\213k\231+\217”
irb(main):673:0> c=Cipher.new(“DES-CBC”)
irb(main):674:0> c.key=key
irb(main):675:0> c.iv=iv
irb(main):676:0> c.encrypt
irb(main):677:0> wackjob_ctext=c.update(plain)+c.final
=>
“Y\322\325T8As\226\360\t\335\3329\257\366\263WW\024<A\2632vg\026\a\353G\217
237\004\264\t\263\353H\305\351$”

Note that this is the same as what I am receiving except for the
trailing
\264\t\263\353H\305\351$

irb(main):678:0> c.iv=iv
irb(main):679:0> c.decrypt
irb(main):680:0> c.update(wackjob_ctext)+c.final == plain
=> true
irb(main):681:0> c.iv=iv

The ctext I am getting has no wacky last byte, nor should it as far as I
can
tell, since it’s 8 byte aligned and DES has an 8 byte blocksize. Let’s
try
it…

irb(main):682:0> c.update(ctext)
=>
“\010\000\000\f\001\000\000\000\254\020#\200\000\000\000\024\254\2749\350\22
6t\235k”

Well that’s mostly right, but you stole my last block! Give it up!

irb(main):683:0> c.final
(irb):683: warning: error on stack: error:06065064:digital envelope
routines:EVP_DecryptFinal:bad decrypt
OpenSSL::CipherError: error:06065064:digital envelope
routines:EVP_DecryptFinal:bad decrypt
from (irb):683:in `final’
from (irb):683
from :0

Ow, something blew up. :frowning:

Try again…

irb(main):684:0> c.iv=iv

Let’s use any extra 8 bytes, just so we can extract our plaintext…

irb(main):685:0> c.update(ctext+“WHATEVER”)==plain
=> true

Hm. Yay, I guess. Just don’t call the final method, or…

irb(main):686:0> c.final
(irb):686: warning: error on stack: error:06065064:digital envelope
routines:EVP_DecryptFinal:bad decrypt
OpenSSL::CipherError: error:06065064:digital envelope
routines:EVP_DecryptFinal:bad decrypt
from (irb):686:in `final’
from (irb):686
from :0

Boom, again.

So, using the key, IV and plaintext above, if anyone can get OpenSSL to
produce and decrypt the correct ciphertext without the mystery extra
byte I
would be extremely grateful. I was hoping for a “just don’t mess with
this”
flag.

Oh, one more thing, I also tried to use the ‘c.encrypt(key,
iv).update(plain) + c.final’ syntax. It produces something, but it’s
completely different ciphertext to the output using the explicit calls
to
c.key and c.iv as used above. Since there is no documentation it’s hard
to
work out why. Anyone know?

Thanks for any insight, but I post this mainly in case someone else has
the
same problem sometime in the future.

Cheers,

ben