«

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

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));

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

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

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

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