significant figures

[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.

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

 

[Jochen Lehmeier]

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]

$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..

 

[sln]

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

 

[sln]

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 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.


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

 

[Randal L. Schwartz]

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?