Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
1998
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 1998

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: warning for Round[Log[2]/Log[4]]

  • To: mathgroup at smc.vnet.net
  • Subject: [mg13963] Re: warning for Round[Log[2]/Log[4]]
  • From: bruck at math.usc.edu (Ronald Bruck)
  • Date: Fri, 11 Sep 1998 15:06:52 -0400
  • Organization: University of Southern California, Los Angeles, CA
  • References: <6ssvo6$m9r@smc.vnet.net> <6t2l44$47o@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

In article <6t2l44$47o at smc.vnet.net>, Ronald Bruck <bruck at math.usc.edu> wrote:
>In article <6ssvo6$m9r at smc.vnet.net>,
>Wouter Meeussen  <eu000949 at pophost.eunet.be> wrote:
>>** this is not a bug report ***
>>  Windows 3.0.0.0.  
>>
>[That Mathematica didn't have enough precision to compute Round[Log[2]/Log[4]]
>
>Hmmm.  Interesting.  Since Log[2]/Log[4] = 1/2, Mathematica can't decide
>whether to round up or down--it SHOULD apply round-to-even, to give
>zero, but it's trying to do this with just numerical values.
>
>As I recall, deciding when A == B is a profoundly difficult problem. 
>I'm not sure how else one could go about this.  (Oh, sure, the
>immediate problem could be fixed by applying a special rule for
>logarithms, but what about special functions for which the relations
>are still undiscovered?)

I've had an interesting e-mail discussion with...  Hmmm, I suppose the
ethics of the internet prohibit me from saying whom :-(  To summarize:

  The error message is generated by Round[Log[2]/Log[4]], not the //N
part.
  This is because Mathematica attempts to apply purely-numeric
comparisons,
  which can't work of course; after it's tried 66 decimal digits of
precision,
  it punts (returning the correct answer, but how much confidence can
you
  put in that?).

  This is because Mathematica doesn't attempt to simplify the
Log[2]/Log[4]
  term.  In general, it's NOT safe to replace Log[z^2] by 2 Log[z],
because
  this is NOT TRUE (branch problems) in the complex plane.  But surely
  Mathematica knows that Log[a b] = Log[a] + Log[b] for POSITIVE reals
a, b.

  And it does; FullSimplify does the job:

      Round[Log[2]/Log[4]//FullSimplify]

  returns 0.  You have to put the FullSimplify INSIDE the Round, of
course,
  otherwise you get the error message.

  It's interesting that FullSimplify of Log[z^2] returns Log[z^2], of
  Log[z^2]/Log[z] returns Log[z^2]/Log[z], and of Log[4]/Log[2] returns
2.

  This seems to me a reasonable compromise between generality and
specificity.
  Simplify computations which involve Numbers; don't simplify those
which
  involve general variables.  But why couldn't this be incorporated into
  Simplify?

--Ron Bruck




  • Prev by Date: Re: Re: warning for Round[Log[2]/Log[4]]
  • Next by Date: Inequation problem
  • Previous by thread: Re: Re: warning for Round[Log[2]/Log[4]]
  • Next by thread: Re: Re: Re: warning for Round[Log[2]/Log[4]]