develooper Front page | perl.perl5.porters | Postings from February 2001

Re: IV preservation (was Re: [PATCH 5.7.0] compiling on OS/2)

Thread Previous | Thread Next
From:
Ilya Zakharevich
Date:
February 15, 2001 18:47
Subject:
Re: IV preservation (was Re: [PATCH 5.7.0] compiling on OS/2)
Message ID:
20010215214741.B17382@math.ohio-state.edu
On Thu, Feb 15, 2001 at 10:54:57PM +0000, Nicholas Clark wrote:
> > The *only* case when this adds some new functionality is on the
> > platforms with 64-bit floats and 64-bit integers.  These platforms are a tiny
> > minority, and have a possiblity to use long floats intead.  So the
> > patch is not *required*.
> 
> True, it is not required, even on most 64 bit platforms.
> But without it perl is assuming that floating point can fully preserve
> integers. So to maintain numeric sanity while using 64 bit integers one
> has to use long doubles.
> How many platforms have a full set of trigonometric functions at long
> double precision? ANSI C89 doesn't supply them. It doesn't even supply
> square root at anything other than double.

How many functions of what Perl uses are in ANSI C89?  I would think
around 20%...

> 64 bit integers are becoming more desirable, as file sizes increase - 

I have seen no need yet to support file sizes above 10**15 bytes.

> >From what I remember op/numconvert.t went faster with the patch.
> op/numconvert has no sleep, and no fork. Unlike most of test suite.

I think it is doing a lot of RExen and evaling...  Most probably every
arithm operation is inside its own subroutine, which currenlty has an
overhead of circa 2000 cycles.

> > This patch wants to replace some operations done by the FPU by
> > operations in software.  First of all, moving operations from hardware
> > to software is at least a questionable practice.  Second, the
> 
> I believe that you misrepresent what this patch wants to do.
> Or I misunderstand what you say.
> 
> It wants to move *integer* operations from FPU to "software" (read integer
> hardware). All other operations remain in hardware.

All the logic to deside *which* branch it wants to take is in software.

> I believe that this means that the only floating point operation involved
> is determining if a floating point value is actually exactly an integer.
> Why is this a problem?

Do you know what IEEE says about such checks?  Is -0 an integer?  Is
-Inf?  Is NaN?  Etc etc etc.  Checking that a float is an integer is
a non-trivial and a very expensive operation.  [I have no idea how to
answer these questions "correctly".]

> I may get this wrong (it is from memory) but I believe that the majority
> of those still active now who were involved in the discussion of your
> Sane numconvert'ing patch to 5.005_56 at that time expressed a desire to
> have sane numbers using 64 bit IVs. Whilst this could be achieved with
> the structure of 5.6 code, I am under the impression that they were
> desiring 64 bit IVs without moving NVs to long doubles.

My reading of sane numbers is that for most operations you know *in
advance* to which form it will convert its arguments.  The number of
opcodes which inspect the type of the operand, then behave accordingly
(here I mean ++, not & - no *drastic* changes in operation) is
minimal.  Being a few, you can memorize them, then *predict* what your
program is doing.

What Perl taught us is that DWIM is *not always* better than sliced
bread.  By a significant increase in the number of operations which
inspect their arguments, the patch makes prediction harder, not
easier.

> I see your patches for the regular expression engine ending with something
> similar to "XXX is left as an exercise to the reader" and I think
> "help, where would I start?".

I put these remarks only on the patches which *show* what should be
done.  These patches implement all the infrastructures, and
non-infrastructure parts (the only parts which need to be replicated)
are tiny.

You start by inspecting the added infrastructure, and understanding
*why* the replicatable parts are done the way they are done.  You know
where to find me if you need help.  ;-)

> > On the scale of disasters in the Perl design, IMO this is less than
> > the qu// horror, but on par with forcing h2xs to produce a
> 
> >From the documentation of qu// in perlop, I fail to see why it's anywhere
> near as horrible as changes to the numeric operators. I would have thought
> that qu// was less bad, not the other way round.

I found no documentation in perlop!  

             Like the qq manpage but generates Unicode for
             characters whose code points are greater than 128,
             or 0x80.

"Generates Unicode"?  What does it mean?  "Generates bytes"?  How do I
distinguish "generated bytes" from "generated Unicode"?

The principal idea of Unicode support in Perl is that it is
transparent (on the Perl level).  As far as I understand the
implementation, the above documentation says:

  qu// is absolutely identical to qq// (except for some bugs which are
  not fixed yet).

And an operation which produces results identical to qq// should be
named qq//.  Period.  If you want to extend/change the details of how
qq() operates (especially details invisible to the rest of Perl), there
is already a mechanism for this: overloaded constants.

  use unicode ':literals';

  my $var = qq/bar/;

would produce the Unicode-marked string "bar".  Here the
qq-overloading subroutine may look as simple as

  {
    my $empty = substr "\x{101}", 1;
    sub ($) {shift . $empty}
  }

Or call this subroutine qu, and use it as

  my $var = u"bar";

Ilya

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About