significant figures

Discussion in 'Perl Misc' started by dan, Jan 5, 2010.

  1. dan

    dan Guest

    Whilst trying to create something that would parse a number into one with
    an appropriate number of significant figures, I accidentally wrote this:

    sub sigfig {
    my ($sigfigs, $number) = @_;

    my $divisor = 10**(length(int $number) - $sigfigs);
    $number /= $divisor;
    $number = sprintf "%1.0f", $number;
    $number *= $divisor;

    return $number
    }

    which seems to work for positive numbers not in scientific notation.

    As my friends and colleagues consider me big-headed, I would appreciate
    it if somebody could point out any inadequacies,foibles and associated
    notwithstandings of the above code, bringing me down a much needed peg or
    to.

    dan
    dan, Jan 5, 2010
    #1
    1. Advertising

  2. On Tue, 05 Jan 2010 22:38:41 +0100, dan <> wrote:

    > Whilst trying to create something that would parse a number into one with
    > an appropriate number of significant figures, I accidentally wrote this:


    > sub sigfig {
    > my ($sigfigs, $number) = @_;


    $number = sprintf("%d",$number); # just in case...
    return $number if if ($sigfgs > length($number);

    > my $divisor = 10**(length(int $number) - $sigfigs);
    > $number /= $divisor;
    > $number = sprintf "%1.0f", $number;


    # instead:
    $number = sprintf("%d",$number);

    > $number *= $divisor;
    >
    > return $number
    > }


    > inadequacies,foibles and associated notwithstandings of the above code,


    Well, if it works, it works.

    A bit shorter:

    $number = sprintf("%d",$number); # just in case...
    return substr($number,0,$sigfigs) . ("0" x (length($number) -
    $sigfigs));
    Jochen Lehmeier, Jan 6, 2010
    #2
    1. Advertising

  3. On Wed, 06 Jan 2010 21:52:51 +0100, John Stanley <> wrote:

    > $number = sprintf("%d", $number); # just in case ...
    > return $number if $sigfigs > length($number);
    >
    > shows an even more amazing lack of understanding of significant figures.
    > It would return "1" for sigfigs 4, 1.234, which is patently absurd.


    That would be me.

    I'm sorry, English is not my primary language. I was not aware that
    "significant figure" has a particular meaning (and yes, Google shows it
    immediately), so misinterpreted his question. I thought his method was
    just for integer numbers, i.e. sigfigs(4,123456)=123400 etc..
    Jochen Lehmeier, Jan 7, 2010
    #3
  4. dan

    Guest

    On Wed, 6 Jan 2010 12:52:51 -0800, John Stanley <> wrote:

    >
    >On Wed, 6 Jan 2010, Ben Morrow wrote:
    >> Quoth dan <>:
    >>> Whilst trying to create something that would parse a number into one with
    >>> an appropriate number of significant figures, I accidentally wrote this:
    >>>
    >>> sub sigfig {
    >>> my ($sigfigs, $number) = @_;
    >>>
    >>> my $divisor = 10**(length(int $number) - $sigfigs);
    >>> $number /= $divisor;
    >>> $number = sprintf "%1.0f", $number;
    >>> $number *= $divisor;
    >>>
    >>> return $number
    >>> }
    >>>
    >>> which seems to work for positive numbers not in scientific notation.

    >>
    >> It fails for cases like
    >>
    >> sigfigs 2, 0.00123;
    >>
    >> Ben

    >
    >And for sigfigs 7, 123
    >
    >The auto-conversion of numbers to strings and back in perl makes it
    >difficult to manage significant figures without keeping that information
    >separately. Even something simple like:
    >
    >$number = "123.0000";
    >print "$number\n";
    >print $number + 1.0000 . "\n";
    >print "$number" + "1.0000" . "\n";
    >
    >shows the loss of information about significance. The only printed result
    >that is correct wrt sig-figs is the first, and that's only because $number
    >started as a string and was printed as a string. In the latter two cases,
    >the addition forced the conversion.


    $number started as a string and ended as a string.
    You should assume that general rules of temporaries still apply ..
    even in Perl. In fact, in your above example, $number was never
    alterred, just assigned once.
    There was no conversion of $number at all as this proves:
    ----
    my $number = "123.0000";
    print "$number\n";
    print $number + 1.0000 . "\n";
    print "$number" + "1.0000" . "\n";
    print "Nope, still a string -> ", $number, "\n";
    $number += "0.0000";
    print "Now its a number -> ", $number, "\n";
    ----
    123.0000
    124
    124
    Nope, still a string -> 123.0000
    Now its a number -> 123
    ----

    I don't care what language your in, source code
    constants at compile time, are converted to either a number or a string.
    "123.0000" is a char(10), and 123.0000 is a float().
    In eazy Perl pseudo, its the same as
    struct {
    char *c;
    float f;
    ... more
    TYPE last;
    } number;

    Temporaries are still the same and conversions only
    happen on assignments.
    I don't think its too tricky to understand that numeric
    operations should be homogenous, and print is just a conversion,
    accurate or not, of a temporary, a snapshot of the variable,
    in space and time, that has absolutely nothing to do with assigning
    to the variable.

    There is nothing extrordinary about Perl in that regard, same numeric
    base conversion problems as any other language.

    In the OP's example code, assuming $number was passed in as a number,
    then this line: $number = sprintf "%1.0f", $number;
    is a problem. But it would be no less a problem if done in C++:
    number = atof ( sprintf( "%1.0f", number) );
    This does not maintain numeric integrity in any language.

    -sln
    , Jan 11, 2010
    #4
  5. dan

    Guest

    On Mon, 11 Jan 2010 20:10:45 -0800, John Stanley <> wrote:

    >On Mon, 11 Jan 2010, wrote:
    >
    >> On Wed, 6 Jan 2010 12:52:51 -0800, John Stanley <> wrote:
    >>
    >>>
    >>> The auto-conversion of numbers to strings and back in perl makes it
    >>> difficult to manage significant figures without keeping that information
    >>> separately. Even something simple like:

    >>
    >> $number started as a string and ended as a string.

    >
    >I did not say that the contents of $number changed without an assignment,
    >I said that the value was converted from string to numeric as necessary.
    >
    >> I don't think its too tricky to understand that numeric
    >> operations should be homogenous, and print is just a conversion,
    >> accurate or not, of a temporary, a snapshot of the variable,
    >> in space and time, that has absolutely nothing to do with assigning
    >> to the variable.

    >
    >I didn't say it was tricky to understand, and I didn't say that print
    >assigned anything to anything. 'Print' was there only to show the result
    >of the operations being performed on the values.
    >
    >> There is nothing extrordinary about Perl in that regard, same numeric
    >> base conversion problems as any other language.

    >
    >Perl is unique in the sense that it will AUTOMATICALLY convert from string
    >to number when it is performing operations that require it. Other
    >languages, at least those I am familiar with, require the programmer to
    >know which is which and convert as required.
    >

    I'm sure there are other typeless languages out there.

    >While there was no actual conversion of the stored values in the code I
    >wrote, it was trivial demo code showing the loss of information by the
    >operations themselves, and you would expect real code would have a few
    >assignments saving the incorrect results.


    Yes, I agree entirely. My point was that real code involving
    numeric calculations won't mix string/number conversions except on entry
    points or initialization, and coerce to a number if its a typeless language
    if the language supports that. Even in Perl you can do that if precautions
    are taken.

    So significance is ludicrous in the OP's context of conversion, then assignment.
    Precision is everything, the least precise number as it interracts with calculations,
    is the limiting factor of significance. Significance is secondary.

    I wouldn't use Perl as a numerical methods language, but it could be done.
    For engineers/math types usually thier first project in Perl is to try to
    convert some numeric project, and the freewheeling conversions are a trap for them.
    I think the term "automatic conversion" is a misnomer since clearly one can
    usually point to the offending line of code involving string assignment or
    cataenation/assignment operators. Once the string side is breaced, the variable
    is tainted with respect to numeric calculations. There should only be one way
    conversions, number -> temporary -> string -> print. Entry points are a different
    issue.

    -sln
    , Jan 12, 2010
    #5
  6. >>>>> "Shmuel" == Shmuel (Seymour J ) Metz <> writes:

    >> Perl is unique in the sense that it will AUTOMATICALLY convert from
    >> string to number


    Shmuel> Rexx, which is older than Perl. "There may be many others but they haven't
    Shmuel> been discovered."

    I believe Awk also did this just fine. Does Rexx predate Awk?

    --
    Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
    <> <URL:http://www.stonehenge.com/merlyn/>
    Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
    See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
    Randal L. Schwartz, Jan 13, 2010
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steve
    Replies:
    5
    Views:
    42,642
    Steve
    May 17, 2004
  2. Jeremy Watts

    more than 16 significant figures

    Jeremy Watts, Jul 4, 2005, in forum: Java
    Replies:
    32
    Views:
    1,290
    Tom N
    Jul 15, 2005
  3. Alf P. Steinbach

    Re: Round to significant figures (C++)

    Alf P. Steinbach, May 1, 2006, in forum: C++
    Replies:
    0
    Views:
    713
    Alf P. Steinbach
    May 1, 2006
  4. Harold

    Significant figures calculation

    Harold, Jun 24, 2011, in forum: Python
    Replies:
    16
    Views:
    1,183
  5. SMH
    Replies:
    0
    Views:
    208
Loading...

Share This Page