On 5/27/05, Jim Weirich <jim / weirichhouse.org> wrote:
> 
> Glenn Parker said:
> > There is no backwards or forwards here.
> 
> As long as we are only talking asthetics, then I agree that either choice
> is co-equal, neither is backwards or forwards.  In fact, I would tend to
> agree that sqrt(n) is more asthetically pleasing than n.sqrt.
> 
> However ...
> 
> But if we are talking maintenance (cf. "[sqrt as a method] spreads the
> definition out, which complicates maintainence"), then I think it is clear
> that the method implementation is (1) no more "spread out" that the
> current implementation, (2) simpler to extend to for new types (e.g.
> Complex).  It is the stand-alone function (not method) implementation that
> complicates maintainence.  That is the part I thought was backwards.

'mathn' tries to patch the sqrt functionality, but doesn't get it
completely. look at the inconsistencies in the following examples,
remembering that precisely, sqrt(-1) should yield Complex(0,1) (aka:
"i"), and sqrt(n) is exactly the same as n**(1/2):

  require 'mathn'
    ==>true
  Math.sqrt(-1)
    ==>Complex(0, 1)
  (-1)**(1/2)
    ==>Complex(6.12323399573677e-17, 1.0)
  (-1)**0.5
    ==>NaN
  Math.sqrt(-1.0)
    ==>Complex(0, 1.0)
  (-1.0)**(1/2)
    ==>NaN
  (-1.0)**(0.5)
    ==>NaN

These all should have given either Complex(0, 1) or Complex(0, 1.0).
The one with the tiny float value could be given an "A" for effort,
perhaps, but NaN? Really, now.

If sqrt was added as a method, it could be defined as self ** 0.5, and
I imagine it would be much easier to keep everything in sync.
Requiring 'mathn' would change that to self ** (1/2), and then
override **() to handle rationals.

just my 2
Mark