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.
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
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)
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.
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.
In article
[email protected],
“Minkoo S.” [email protected] 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.
Hi,
In message “Re: What do you say to log2 to Math module?”
on Fri, 5 May 2006 09:34:44 +0900, Tanaka A. [email protected]
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.
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?
-----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-----
-----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-----
Thank you for your time and effort!!
Sincerely,
Minkoo S.
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
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
Hi,
In message “Re: What do you say to log2 to Math module?”
on Fri, 5 May 2006 11:12:38 +0900, Logan C.
[email protected] 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.
On 06/05/06, M. Edward (Ed) Borasky [email protected] 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
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 forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs