Re: Huffman's Log: svndate r27485
David Green wrote: On 2009-Jul-8, at 3:41 pm, pugs-comm...@feather.perl6.nl wrote: =item log + our Num multi method log ( Num $x: Num $base = Num::e ) is export Logarithm of base C$base, default Natural. Calling with C$x == 0 is an error. It occurs to me that log is a pretty short name for a function I rarely use. (In fact, I'm not sure I've ever used it in perl.) On the other hand, I -- and a thousand or so CPAN modules -- are always logging stuff in that other popular computer sense. (All right, that number isn't exactly the result of a rigourous study... I did find 57 modules that mentioned logarithms.) The inertia of tradition weighs heavily here, but perhaps we could call it ln(). (If anyone asks, I'm prepared to say with a straight face that it stands for log (numeric).) And/or log(), but with the :base arg mandatory -- then as long as your status logging doesn't have a :base, you can have both. If you're going to have a ln to mean some kind of logarithm, then the only thing that makes sense is for it to mean natural logarithm or N log e. Also, plain log should be a dyadic infix or prefix operator where you can use any base/radix. If you want something to mean log to the base 10 then it should be spelled say log10, not log. See, log is the most generic version of the name and so it should be the most generic version of the operator, taking base as an argument. -- Darren Duncan
Re: Huffman's Log: svndate r27485
+1 on using ln() instead of log() Also, systems I know of that implement both log() and ln() default ln() with base e, as perl6 does, log() uses base 10.
Re: Huffman's Log: svndate r27485
ln() for log(:base(e)) is fine. ln() for log to any other base is
Just Plain Wrong.
The clash between 'log' for 'logarithm' and 'log' for 'write to log
file' is unfortunate, but since you have to define logging parameters
somewhere anyway, I'm OK with having to call that sort of log as a
method on a logger object instead of as a top-level sub.
All's fair if you predeclare, so you could use MMD to define log(Str)
as a shortcut for writing to the log, but that's going to surprise
folks who are used to log('1') returning 0.
On Fri, Jul 10, 2009 at 3:16 PM, yarynot@gmail.com wrote:
+1 on using ln() instead of log()
Also, systems I know of that implement both log() and ln() default
ln() with base e, as perl6 does, log() uses base 10.
--
Mark J. Reed markjr...@gmail.com
Re: Huffman's Log: svndate r27485
On Fri, Jul 10, 2009 at 3:32 PM, Mark J. Reed markjr...@gmail.com wrote: The clash between 'log' for 'logarithm' and 'log' for 'write to log file' is unfortunate, but since you have to define logging parameters somewhere anyway, I'm OK with having to call that sort of log as a method on a logger object instead of as a top-level sub. It none-the-less leaves ambiguity. I think the right way to attack it is to have log() be an un-imported-by-default alias for the automatically imported function in both logging and math modules. Thus someone who is just too attached to log() can have it, but everyone else can get by with the imported-by-default name. So, for example: logbase($x,$base) = log in the given base, no default log10($x) = logbase($x,10), log in base 10 logn($x) = logbase($x,$Math::e), log in base e log($x) = unexported logbase($x,$base=$Math::e), log in base e by default Most people will likely use logn and log10 most of the time, and these names are not unique to Perl.
Re: Huffman's Log: svndate r27485
David Green wrote: It occurs to me that log is a pretty short name for a function I rarely use. (In fact, I'm not sure I've ever used it in perl.) On the other hand, I -- and a thousand or so CPAN modules -- are always logging stuff in that other popular computer sense. (All right, that number isn't exactly the result of a rigourous study... I did find 57 modules that mentioned logarithms.) The inertia of tradition weighs heavily here, but perhaps we could call it ln(). (If anyone asks, I'm prepared to say with a straight face that it stands for log (numeric).) And/or log(), but with the :base arg mandatory -- then as long as your status logging doesn't have a :base, you can have both. Umm. At the risk of pointing out the obvious, P6 has redefined the syntax of regular expressions, converted bitwise negation into a stringification unary and a binary catenation operator, and torqued a bunch of other keywords and line noise^W^Woperator characters out of shape. Do we really give a rat's posterior about the historical legacy of a mathematical function that (statistically) never gets called? Like everything else mathematical, jam it into a Math:: class and clean up the default namespace. (FWIW: My perl scripts don't do logs, in EITHER sense of the word. I don't want to replace one bit of namespace clutter with another one. All you web guys can use the Apache::log method, or whatever.) =Austin
Re: Huffman's Log: svndate r27485
I'm all for not having any variety of log() in the default namespace. Regardless, mathematical functions should follow mathematical norms. Changing Perl tradition is one thing, but we have centuries, sometimes millennia, of tradition to deal with in the mathematical realm. It should not be violated lightly. On 7/10/09, Austin Hastings austin_hasti...@yahoo.com wrote: David Green wrote: It occurs to me that log is a pretty short name for a function I rarely use. (In fact, I'm not sure I've ever used it in perl.) On the other hand, I -- and a thousand or so CPAN modules -- are always logging stuff in that other popular computer sense. (All right, that number isn't exactly the result of a rigourous study... I did find 57 modules that mentioned logarithms.) The inertia of tradition weighs heavily here, but perhaps we could call it ln(). (If anyone asks, I'm prepared to say with a straight face that it stands for log (numeric).) And/or log(), but with the :base arg mandatory -- then as long as your status logging doesn't have a :base, you can have both. Umm. At the risk of pointing out the obvious, P6 has redefined the syntax of regular expressions, converted bitwise negation into a stringification unary and a binary catenation operator, and torqued a bunch of other keywords and line noise^W^Woperator characters out of shape. Do we really give a rat's posterior about the historical legacy of a mathematical function that (statistically) never gets called? Like everything else mathematical, jam it into a Math:: class and clean up the default namespace. (FWIW: My perl scripts don't do logs, in EITHER sense of the word. I don't want to replace one bit of namespace clutter with another one. All you web guys can use the Apache::log method, or whatever.) =Austin -- Sent from my mobile device Mark J. Reed markjr...@gmail.com
Re: Huffman's Log: svndate r27485
Mark J. Reed wrote: I'm all for not having any variety of log() in the default namespace. Regardless, mathematical functions should follow mathematical norms. Changing Perl tradition is one thing, but we have centuries, sometimes millennia, of tradition to deal with in the mathematical realm. It should not be violated lightly. That's okay. Preserve their thousands of years of historical legacy. Just preserve it in a separate container. #! /usr/bin/perl6 say(log(1000, 10)); # Error - no such function log use Math::Simple; say(log(1000, 10)); # 2.999...
Re: Huffman's Log: svndate r27485
On Fri, Jul 10, 2009 at 2:22 PM, Austin Hastingsaustin_hasti...@yahoo.com wrote: Mark J. Reed wrote: I'm all for not having any variety of log() in the default namespace. Regardless, mathematical functions should follow mathematical norms. Changing Perl tradition is one thing, but we have centuries, sometimes millennia, of tradition to deal with in the mathematical realm. It should not be violated lightly. That's okay. Preserve their thousands of years of historical legacy. Just preserve it in a separate container. #! /usr/bin/perl6 say(log(1000, 10)); # Error - no such function log use Math::Simple; say(log(1000, 10)); # 2.999... Ugh; no thanks. However, it occurs to me that when you log messages, you should specify where you're logging them as well as what they are. log(Str) might lead to ambiguous results; but IO.log(Str) should be pretty clear. But maybe I'm not understanding what people are wanting out of message logging. -- Jonathan Dataweaver Lang
Re: Huffman's Log: svndate r27485
It occurs to me that ln() is even shorter than log(), leaving the Huffmanization issue unresolved. :)
