in reply to Re^3: Determining the minimum representable increment/decrement possible? (Perl's scanf broken?)
in thread Determining the minimum representable increment/decrement possible?

Sadly, no-one seems interested in fixing this - though I think that's because of the degree of difficulty rather than actual "disinterest".

I'm somewhat confused by that. Why not use the underlying CRTs sscanf() or strtod()?

one solution is to assign using POSIX::strtod

That's very useful! Thankyou.

I'd rather put my faith in the mpfr library.

For the most part, I'm only really using Perl as an interactive calculator for exploring the issues; the actual code is C++; and I'm doing some optimisations in x64 assembler.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
In the absence of evidence, opinion is indistinguishable from prejudice. Not understood.
  • Comment on Re^4: Determining the minimum representable increment/decrement possible? (Perl's scanf broken?)

Replies are listed 'Best First'.
Re^5: Determining the minimum representable increment/decrement possible? (Perl's scanf broken?)
by syphilis (Archbishop) on Jun 17, 2016 at 15:22 UTC
    Why not use the underlying CRTs sscanf() or strtod()?

    I don't know.
    I speculate that in earlier times those functions were not so reliable and it was decided that perl should do its own implementation.
    I further speculate that it has now got to the stage that unwinding that perl implementation is not a trivial task.

    Cheers,
    Rob
[reply]

      Grr. I had a notion to try and work out what code Perl was actually using to parse doubles and 'forgot' my rule of the last few years: don't go looking in the recent perl sources; it will only piss you off.

      It pissed me off. It used to be that you could compile Perl to use stdio, and I thought I might do that for 5.22; but apparently that is not longer possible!

      Perl is still my go-to language for getting stuff done in a hurry; and in many cases even when the program has ultimately to be written in some compiled language, whether for speed or to satisfy some other requirement, I still use Perl to prototype and only convert to C or C++ or D or whatever once I have the code working.

      But for the last few years, the P5 development has become introspective, even introverted; titivating instead of innovating; throwing any weird idea that comes up into the code base only to remove it a build or two later. I've lost track of the number of "experimental" additions that have come and inevitably gone.

      It's just a shame that PerlIO isn't so easily back out and discarded! :(

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
      In the absence of evidence, opinion is indistinguishable from prejudice. Not understood.
[reply]
        I hadn't thought of building perl without USE_PERLIO.
        That would have been interesting - and I agree that it's a pity that the option has been taken away.

        Cheers,
        Rob
[reply]

        Only two experimental features were removed:

        • Passing a reference to key/values/each

          I don't know why that was released in the first place given it was known to be broken before it was even coded.

        • my $_;

          It was causing code like apply { s/foo/bar/ } @a to break in a manner that was confusing for too many.

        Smart-matching and given/when have been experimental for a while, but they are not dead. The subject came up again this week. There are strong intentions to fix it.

[reply]
[d/l]
[select]
Re^5: Determining the minimum representable increment/decrement possible? (Perl's scanf broken?)
by ikegami (Patriarch) on Jun 19, 2016 at 04:45 UTC

    Why not use the underlying CRTs sscanf() or strtod()?

    I think differences in stringifications of Inf and NaN played a roll.

[reply]

In Section Seekers of Perl Wisdom