Forum: Ruby What do you say to log2 to Math module?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
47b36de21d7ecbc824c81d24802a6290?d=identicon&s=25 Minkoo Seo (pool007)
on 2006-05-03 21:54
(Received via mailing list)
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 Seo
0b561a629b87f0bbf71b45ee5a48febb?d=identicon&s=25 Dave Burt (Guest)
on 2006-05-03 23:50
(Received via mailing list)
Minkoo Seo 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
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-05-04 02:13
(Received via mailing list)
On May 3, 2006, at 5:47 PM, Dave Burt 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)
47b36de21d7ecbc824c81d24802a6290?d=identicon&s=25 Minkoo Seo (pool007)
on 2006-05-04 22:15
(Received via mailing list)
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 Seo
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-05-04 22:30
(Received via mailing list)
On May 4, 2006, at 4:12 PM, Minkoo Seo 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 Seo

http://www.rcrchive.net/
42c83263598da02c136a4ebf8a058182?d=identicon&s=25 Tanaka Akira (Guest)
on 2006-05-05 02:35
(Received via mailing list)
In article
<f9082cd90605041312x48f5d110p6e8ddb0b753a0133@mail.gmail.com>,
  "Minkoo Seo" <minkoo.seo@gmail.com> 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.
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2006-05-05 03:48
(Received via mailing list)
Hi,

In message "Re: What do you say to log2 to Math module?"
    on Fri, 5 May 2006 09:34:44 +0900, Tanaka Akira <akr@m17n.org>
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.
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-05-05 04:15
(Received via mailing list)
On May 4, 2006, at 9:46 PM, Yukihiro Matsumoto 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?
8d775a4f841200707929b36728efcccf?d=identicon&s=25 Suraj N. Kurapati (Guest)
on 2006-05-05 05:33
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Minkoo Seo 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-----
8d775a4f841200707929b36728efcccf?d=identicon&s=25 Suraj N. Kurapati (Guest)
on 2006-05-05 05:39
(Received via mailing list)
-----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-----
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2006-05-05 11:05
(Received via mailing list)
Hi,

In message "Re: What do you say to log2 to Math module?"
    on Fri, 5 May 2006 11:12:38 +0900, Logan Capaldo
<logancapaldo@gmail.com> 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.
47b36de21d7ecbc824c81d24802a6290?d=identicon&s=25 Minkoo Seo (pool007)
on 2006-05-06 11:15
(Received via mailing list)
Thank you for your time and effort!!

Sincerely,
Minkoo Seo
3bb23e7770680ea44a2d79e6d10daaed?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2006-05-06 20:42
(Received via mailing list)
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 Seo wrote:
>
> Sincerely,
> Minkoo Seo
>

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-05-06 20:49
(Received via mailing list)
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
893c38bd5f182afc751540657d8aacf7?d=identicon&s=25 Stefano Taschini (Guest)
on 2006-05-08 12:30
(Received via mailing list)
On 06/05/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> 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
Ce263187f309d71b404399802b7f7906?d=identicon&s=25 Ben Nagy (Guest)
on 2006-05-08 12:58
(Received via mailing list)
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. :(

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
This topic is locked and can not be replied to.