[31505] in Perl-Users-Digest
Perl-Users Digest, Issue: 2764 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jan 12 06:09:42 2010
Date: Tue, 12 Jan 2010 03:09:08 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 12 Jan 2010 Volume: 11 Number: 2764
Today's topics:
"lazy" handling of namespaces in XML::LibXML::Parser? <bugbear@trim_papermule.co.uk_trim>
Re: Error when combining threads and system() <sysadmin@example.com>
Re: Error when combining threads and system() <google@markginsburg.com>
Re: my $short = (split /\//, $Server->File())[$#] <sysadmin@example.com>
Re: my $short = (split /\//, $Server->File())[$#] sln@netherlands.com
Re: perl in BartPE: locale warning <keith.watson@cc.gatech.edu>
Posting Guidelines for comp.lang.perl.misc ($Revision: tadmc@seesig.invalid
Re: significant figures sln@netherlands.com
Re: significant figures <stanley@peak.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 12 Jan 2010 09:58:09 +0000
From: bugbear <bugbear@trim_papermule.co.uk_trim>
Subject: "lazy" handling of namespaces in XML::LibXML::Parser?
Message-Id: <MfednfcJudEs2tHWnZ2dnUVZ7qednZ2d@brightview.co.uk>
I am looking to change from using XML::DOM (old and busted)
to using XML::LibXML (new hotness).
At the moment, when handling the sprawling nightmare that
is AdsML, I exploit "namespace" processing provided by the underlying
Expat parser.
Quoting the docs:
"When this option is given with a true value, then the
parser does namespace processing. By default, namespace processing
is turned off. When it is turned on, the parser consumes
xmlns attributes and strips off prefixes from element
and attributes names where those prefixes have a defined namespace."
Since AdsML is (in practice) versbose and redundant, it is unambiguous
at the level of XPath's without needing to handle namespaces.
I would like to retain this pragmatic convenience.
But it appears that XML::LibXML, and XML::LibXML::Parser,
XML::LibXML::XPathContext are keen to force me to handle
namespaces explicitly, which is a workload I could well do without.
The parser is keen to retain namespaces, and XPath is keen
for me to name them all.
I have considered walking the DOM tree to set all the namespaces
of all the nodes to "default", but I suspect this would have performance
implications.
Any "shortcuts" would be welcomed.
BugBear
------------------------------
Date: Sun, 10 Jan 2010 23:02:30 -0800
From: Wanna-Be Sys Admin <sysadmin@example.com>
Subject: Re: Error when combining threads and system()
Message-Id: <c2A2n.11693$YP1.11605@newsfe15.iad>
Willem wrote:
> Hi,
>
> I'm having a weird problem involving threads and calls to system()
>
> Note: it only fails on some systems, notably a Windows NT 2003 server.
>
> The issue is that when I call system() in the main thread, everything
> works like it should, but when I call it in a subthread, it fails with
> the following message:
>
> Can't spawn "cmd.exe": No such file or directory at test-bug.pl line
> 10. foo
>
I haven't used Windows in years and years, I'm glad to say, but I'd be
curious if there's any difference for $PATH in the sub thread.
--
Not really a wanna-be, but I don't know everything.
------------------------------
Date: Mon, 11 Jan 2010 16:43:43 -0800 (PST)
From: Mark <google@markginsburg.com>
Subject: Re: Error when combining threads and system()
Message-Id: <1fdb1532-674e-41ef-8269-1a60b311c92a@26g2000yqo.googlegroups.com>
On Jan 8, 10:51=A0am, Willem <wil...@stack.nl> wrote:
> Hi,
>
> I'm having a weird problem involving threads and calls to system()
>
> Note: it only fails on some systems, notably a Windows NT 2003 server.
>
> The issue is that when I call system() in the main thread, everything wor=
ks
> like it should, but when I call it in a subthread, it fails with the
> following message:
>
> =A0 Can't spawn "cmd.exe": No such file or directory at test-bug.pl line =
10.
> =A0 foo
>
> This is the test program as minimal as I could get it:
>
> =A0 use warnings;
> =A0 use strict;
> =A0 use threads;
> =A0 threads->create(\&tests)->join();
> =A0 tests();
> =A0 sub tests { system('echo foo') }
>
> It fails on both perl 5.8.8 built for MSWin32-x86-multi-thread
> and perl 5.10.x, using Activestate.
>
> The value of $? seems to be 255<<8, so that's a return code
> of -1 from the shell.
>
> Piped open fails as well, as do backticks. =A0Probably for the same reaso=
n.
> Can anyone shed any light on this ? =A0I've tried googling, but I haven't
> found anything specific to threading.
>
> SaSW, Willem
> --
> Disclaimer: I am in no way responsible for any of the statements
> =A0 =A0 =A0 =A0 =A0 =A0 made in the above text. For all I know I might be
> =A0 =A0 =A0 =A0 =A0 =A0 drugged or something..
> =A0 =A0 =A0 =A0 =A0 =A0 No I'm not paranoid. You all think I'm paranoid, =
don't you !
> #EOT
I was unable to recreate the problem on my W2003 server with perl
5.8.6 and this may be reaching but it could be a file security issue
with cmd.exe.
Non-administrator interactive users have Read+Execute permission on
%SystemRoot%\system32\cmd.exe. But, if the system has classified your
process thread as non-interactive and not in the Administrators group,
the thread will not have read access to cmd.exe which would account
for the "No such file or directory" error. Check out the permissions
on cmd.exe and note the special "INTERACTIVE" group and the
permissions assigned.
You might try adding Read+Execute permisson to cmd.exe for whatever
user context the thread runs under. If it works then it's a
permission problem and you can go from there.
------------------------------
Date: Sun, 10 Jan 2010 16:47:36 -0800
From: Wanna-Be Sys Admin <sysadmin@example.com>
Subject: Re: my $short = (split /\//, $Server->File())[$#]
Message-Id: <Iyu2n.3817$%P5.3091@newsfe21.iad>
cate wrote:
> Is it possible to do something like that? I can make it work with in
> index number. I can make it work with the last array index.
>
> my $short = (split /\//, $Server->File())[$#]
Sure you can do it, but not with $Server->File(), since it's not an
array. Of course, you can build an array by using / as a delimiter and
then split, but that would be doing double the work when you can
determine the last element by split in the first place, or by using a
regex instead.
--
Not really a wanna-be, but I don't know everything.
------------------------------
Date: Mon, 11 Jan 2010 09:46:51 -0800
From: sln@netherlands.com
Subject: Re: my $short = (split /\//, $Server->File())[$#]
Message-Id: <qpomk5p158sasrlt569duutncsonqc781q@4ax.com>
On Sun, 10 Jan 2010 10:04:01 -0800 (PST), cate <catebekensail@yahoo.com> wrote:
>Is it possible to do something like that? I can make it work with in
>index number. I can make it work with the last array index.
>
> my $short = (split /\//, $Server->File())[$#]
>
>Thank you.
Not really a good way to do it.
Untested.
$short = (reverse split(/\//, $Server->File) )[0] || 'empty';
or
$short = (@_= split /\//, $Server->File )[$#_] || 'empty';
-sln
------------------------------
Date: Mon, 11 Jan 2010 14:11:07 +0000 (UTC)
From: "Keith R. Watson" <keith.watson@cc.gatech.edu>
Subject: Re: perl in BartPE: locale warning
Message-Id: <hifbhr$ofv$1@news-int2.gatech.edu>
Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote in
news:slrnhkctb7.bhv.nospam-abuse@powdermilk.math.berkeley.edu:
> On 2010-01-06, Keith R. Watson <keith.watson@cc.gatech.edu> wrote:
>>> Why? Cannot BartPE "just load the .reg" file at runtime?
>
>> You could try the following:
> ...
>> 3. Boot the machine with the BartPE CD.
>> 4. Import the .reg files
>
> This is exactly the procedure I was asking about. So why did your
> plugin goes in circles (via the main HIV of BartPE) instead of going
> this itself (only, of course, automated)?
>
> This might add half-a-second to boot time, but would make
> customization so much easier...
>
>> settings. However, I don't know if the locale settings take effect
>> immediately or not. Some registry keys work as soon as you change
>> them in the registry and others require telling the operating system
>> to reload their settings from the registry. You could try it and see
>> if it works.
>
> AHA! This might answer my question... Unfortunately, right now I do
> not have a Windows machine at hand to export the .reg file (I would
> use US)...
>
> On the other hand, switching users may switch the locale at runtime,
> right? So it looks like this setting MUST have immediate effect.
>
>>> And, btw, would not BartPE-builder be able to emit .reg for a
>>> certain subtree automatically?
There are three possible scenarios when you make a registry change.
1. Processes that continually monitor for changes in the registry so when
they are made with any tool, including the command line, the changes take
effect immediately.
2. Processes that get their settings from the registry but never read them
again unless they are told to. If you change the settings for one of these
from the command line the settings will not take effect immediately. You
have to make a Windows system call to tell the process to re-read its
settings. Several of the control panel applets have this function built
into them. If the use the control panel applet the change is immediate
however, if you use a command line utility to modify the registry the
changes will not take effect. If you know the system call that needs to be
made it is possible to write a program that will do it for you from the
command line.
3. Processes that get their settings from the registry but never read them
again and there is no way to tell them to. When you change the registry
settings for a process like this you have to reboot the system in order for
them to take effect.
>
>> When you the BartPE utility runs it gets the Windows files from a
>> Windows install CD and not from the machine the utility is running
>> on. There are not registry keys on the Windows install CD for it to
>> export.
>
> My question was, in fact, more about "tools" than about the actually
> used procedure. Are there command-line tools to emit the .reg file
> for the given subtree of a running system?
There are several tools that will allow you to dump registry settings to a
file and then import them into the registry.
regdmp.exe
regini.exe
reg.exe
regedit.exe
regedit.exe is the one most people are familiar with.
To export registry settings from
"HKEY_CURRENT_USER\Control Panel\International"
To the file foo.reg in Regedit v5 format use the following syntax:
regedit.exe /e foo.reg "HKEY_CURRENT_USER\Control Panel\International"
to export them in Regedit v4 format use the following syntax:
regedit.exe /a /e foo.reg "HKEY_CURRENT_USER\Control Panel\International"
To import the registry settings use the following syntax:
regedit.exe foo.reg
You will get several GUI prompts so if you want it to do it silently use
the following syntax:
regedit.exe /s foo.reg
>
> I see that you explicitly mention Perl in your plugin. It may be
> simpler with Perl, right?
>
> Thanks again,
> Ilya
>
> P.S. I have not googled for it yet, but maybe people here know right
> away about installing keyboard layouts with BartPE?
To do keyboard layouts you use the same process. You just have to know what
keys in registry control they layout.
Use this Google search
windows registry keyboard layout
keith
--
Keith R. Watson Georgia Institute of Technology
Systems Support Specialist IV College of Computing
keith.watson@cc.gatech.edu 801 Atlantic Drive NW
(404) 385-7401 Atlanta, GA 30332-0280
------------------------------
Date: Tue, 12 Jan 2010 02:13:23 -0600
From: tadmc@seesig.invalid
Subject: Posting Guidelines for comp.lang.perl.misc ($Revision: 1.9 $)
Message-Id: <hPmdnV60r4m-stHWnZ2dnUVZ_t2dnZ2d@giganews.com>
Outline
Before posting to comp.lang.perl.misc
Must
- Check the Perl Frequently Asked Questions (FAQ)
- Check the other standard Perl docs (*.pod)
Really Really Should
- Lurk for a while before posting
- Search a Usenet archive
If You Like
- Check Other Resources
Posting to comp.lang.perl.misc
Is there a better place to ask your question?
- Question should be about Perl, not about the application area
How to participate (post) in the clpmisc community
- Carefully choose the contents of your Subject header
- Use an effective followup style
- Speak Perl rather than English, when possible
- Ask perl to help you
- Do not re-type Perl code
- Provide enough information
- Do not provide too much information
- Do not post binaries, HTML, or MIME
Social faux pas to avoid
- Asking a Frequently Asked Question
- Asking a question easily answered by a cursory doc search
- Asking for emailed answers
- Beware of saying "doesn't work"
- Sending a "stealth" Cc copy
Be extra cautious when you get upset
- Count to ten before composing a followup when you are upset
- Count to ten after composing and before posting when you are upset
-----------------------------------------------------------------
Posting Guidelines for comp.lang.perl.misc ($Revision: 1.9 $)
This newsgroup, commonly called clpmisc, is a technical newsgroup
intended to be used for discussion of Perl related issues (except job
postings), whether it be comments or questions.
As you would expect, clpmisc discussions are usually very technical in
nature and there are conventions for conduct in technical newsgroups
going somewhat beyond those in non-technical newsgroups.
The article at:
http://www.catb.org/~esr/faqs/smart-questions.html
describes how to get answers from technical people in general.
This article describes things that you should, and should not, do to
increase your chances of getting an answer to your Perl question. It is
available in POD, HTML and plain text formats at:
http://www.rehabitation.com/clpmisc.shtml
For more information about netiquette in general, see the "Netiquette
Guidelines" at:
http://andrew2.andrew.cmu.edu/rfc/rfc1855.html
A note to newsgroup "regulars":
Do not use these guidelines as a "license to flame" or other
meanness. It is possible that a poster is unaware of things
discussed here. Give them the benefit of the doubt, and just
help them learn how to post, rather than assume that they do
know and are being the "bad kind" of Lazy.
A note about technical terms used here:
In this document, we use words like "must" and "should" as
they're used in technical conversation (such as you will
encounter in this newsgroup). When we say that you *must* do
something, we mean that if you don't do that something, then
it's unlikely that you will benefit much from this group.
We're not bossing you around; we're making the point without
lots of words.
Do *NOT* send email to the maintainer of these guidelines. It will be
discarded unread. The guidelines belong to the newsgroup so all
discussion should appear in the newsgroup. I am just the secretary that
writes down the consensus of the group.
Before posting to comp.lang.perl.misc
Must
This section describes things that you *must* do before posting to
clpmisc, in order to maximize your chances of getting meaningful replies
to your inquiry and to avoid getting flamed for being lazy and trying to
have others do your work.
The perl distribution includes documentation that is copied to your hard
drive when you install perl. Also installed is a program for looking
things up in that (and other) documentation named 'perldoc'.
You should either find out where the docs got installed on your system,
or use perldoc to find them for you. Type "perldoc perldoc" to learn how
to use perldoc itself. Type "perldoc perl" to start reading Perl's
standard documentation.
Check the Perl Frequently Asked Questions (FAQ)
Checking the FAQ before posting is required in Big 8 newsgroups in
general, there is nothing clpmisc-specific about this requirement.
You are expected to do this in nearly all newsgroups.
You can use the "-q" switch with perldoc to do a word search of the
questions in the Perl FAQs.
Check the other standard Perl docs (*.pod)
The perl distribution comes with much more documentation than is
available for most other newsgroups, so in clpmisc you should also
see if you can find an answer in the other (non-FAQ) standard docs
before posting.
It is *not* required, or even expected, that you actually *read* all of
Perl's standard docs, only that you spend a few minutes searching them
before posting.
Try doing a word-search in the standard docs for some words/phrases
taken from your problem statement or from your very carefully worded
"Subject:" header.
Really Really Should
This section describes things that you *really should* do before posting
to clpmisc.
Lurk for a while before posting
This is very important and expected in all newsgroups. Lurking means
to monitor a newsgroup for a period to become familiar with local
customs. Each newsgroup has specific customs and rituals. Knowing
these before you participate will help avoid embarrassing social
situations. Consider yourself to be a foreigner at first!
Search a Usenet archive
There are tens of thousands of Perl programmers. It is very likely
that your question has already been asked (and answered). See if you
can find where it has already been answered.
One such searchable archive is:
http://groups.google.com/advanced_search
If You Like
This section describes things that you *can* do before posting to
clpmisc.
Check Other Resources
You may want to check in books or on web sites to see if you can
find the answer to your question.
But you need to consider the source of such information: there are a
lot of very poor Perl books and web sites, and several good ones
too, of course.
Posting to comp.lang.perl.misc
There can be 200 messages in clpmisc in a single day. Nobody is going to
read every article. They must decide somehow which articles they are
going to read, and which they will skip.
Your post is in competition with 199 other posts. You need to "win"
before a person who can help you will even read your question.
These sections describe how you can help keep your article from being
one of the "skipped" ones.
Is there a better place to ask your question?
Question should be about Perl, not about the application area
It can be difficult to separate out where your problem really is,
but you should make a conscious effort to post to the most
applicable newsgroup. That is, after all, where you are the most
likely to find the people who know how to answer your question.
Being able to "partition" a problem is an essential skill for
effectively troubleshooting programming problems. If you don't get
that right, you end up looking for answers in the wrong places.
It should be understood that you may not know that the root of your
problem is not Perl-related (the two most frequent ones are CGI and
Operating System related), so off-topic postings will happen from
time to time. Be gracious when someone helps you find a better place
to ask your question by pointing you to a more applicable newsgroup.
How to participate (post) in the clpmisc community
Carefully choose the contents of your Subject header
You have 40 precious characters of Subject to win out and be one of
the posts that gets read. Don't waste them. Take care while
composing them, they are the key that opens the door to getting an
answer.
Spend them indicating what aspect of Perl others will find if they
should decide to read your article.
Do not spend them indicating "experience level" (guru, newbie...).
Do not spend them pleading (please read, urgent, help!...).
Do not spend them on non-Subjects (Perl question, one-word
Subject...)
For more information on choosing a Subject see "Choosing Good
Subject Lines":
http://www.cpan.org/authors/id/D/DM/DMR/subjects.post
Part of the beauty of newsgroup dynamics, is that you can contribute
to the community with your very first post! If your choice of
Subject leads a fellow Perler to find the thread you are starting,
then even asking a question helps us all.
Use an effective followup style
When composing a followup, quote only enough text to establish the
context for the comments that you will add. Always indicate who
wrote the quoted material. Never quote an entire article. Never
quote a .signature (unless that is what you are commenting on).
Intersperse your comments *following* each section of quoted text to
which they relate. Unappreciated followup styles are referred to as
"top-posting", "Jeopardy" (because the answer comes before the
question), or "TOFU" (Text Over, Fullquote Under).
Reversing the chronology of the dialog makes it much harder to
understand (some folks won't even read it if written in that style).
For more information on quoting style, see:
http://web.presby.edu/~nnqadmin/nnq/nquote.html
Speak Perl rather than English, when possible
Perl is much more precise than natural language. Saying it in Perl
instead will avoid misunderstanding your question or problem.
Do not say: I have variable with "foo\tbar" in it.
Instead say: I have $var = "foo\tbar", or I have $var = 'foo\tbar',
or I have $var = <DATA> (and show the data line).
Ask perl to help you
You can ask perl itself to help you find common programming mistakes
by doing two things: enable warnings (perldoc warnings) and enable
"strict"ures (perldoc strict).
You should not bother the hundreds/thousands of readers of the
newsgroup without first seeing if a machine can help you find your
problem. It is demeaning to be asked to do the work of a machine. It
will annoy the readers of your article.
You can look up any of the messages that perl might issue to find
out what the message means and how to resolve the potential mistake
(perldoc perldiag). If you would like perl to look them up for you,
you can put "use diagnostics;" near the top of your program.
Do not re-type Perl code
Use copy/paste or your editor's "import" function rather than
attempting to type in your code. If you make a typo you will get
followups about your typos instead of about the question you are
trying to get answered.
Provide enough information
If you do the things in this item, you will have an Extremely Good
chance of getting people to try and help you with your problem!
These features are a really big bonus toward your question winning
out over all of the other posts that you are competing with.
First make a short (less than 20-30 lines) and *complete* program
that illustrates the problem you are having. People should be able
to run your program by copy/pasting the code from your article. (You
will find that doing this step very often reveals your problem
directly. Leading to an answer much more quickly and reliably than
posting to Usenet.)
Describe *precisely* the input to your program. Also provide example
input data for your program. If you need to show file input, use the
__DATA__ token (perldata.pod) to provide the file contents inside of
your Perl program.
Show the output (including the verbatim text of any messages) of
your program.
Describe how you want the output to be different from what you are
getting.
If you have no idea at all of how to code up your situation, be sure
to at least describe the 2 things that you *do* know: input and
desired output.
Do not provide too much information
Do not just post your entire program for debugging. Most especially
do not post someone *else's* entire program.
Do not post binaries, HTML, or MIME
clpmisc is a text only newsgroup. If you have images or binaries
that explain your question, put them in a publically accessible
place (like a Web server) and provide a pointer to that location. If
you include code, cut and paste it directly in the message body.
Don't attach anything to the message. Don't post vcards or HTML.
Many people (and even some Usenet servers) will automatically filter
out such messages. Many people will not be able to easily read your
post. Plain text is something everyone can read.
Social faux pas to avoid
The first two below are symptoms of lots of FAQ asking here in clpmisc.
It happens so often that folks will assume that it is happening yet
again. If you have looked but not found, or found but didn't understand
the docs, say so in your article.
Asking a Frequently Asked Question
It should be understood that you may have missed the applicable FAQ
when you checked, which is not a big deal. But if the Frequently
Asked Question is worded similar to your question, folks will assume
that you did not look at all. Don't become indignant at pointers to
the FAQ, particularly if it solves your problem.
Asking a question easily answered by a cursory doc search
If folks think you have not even tried the obvious step of reading
the docs applicable to your problem, they are likely to become
annoyed.
If you are flamed for not checking when you *did* check, then just
shrug it off (and take the answer that you got).
Asking for emailed answers
Emailed answers benefit one person. Posted answers benefit the
entire community. If folks can take the time to answer your
question, then you can take the time to go get the answer in the
same place where you asked the question.
It is OK to ask for a *copy* of the answer to be emailed, but many
will ignore such requests anyway. If you munge your address, you
should never expect (or ask) to get email in response to a Usenet
post.
Ask the question here, get the answer here (maybe).
Beware of saying "doesn't work"
This is a "red flag" phrase. If you find yourself writing that,
pause and see if you can't describe what is not working without
saying "doesn't work". That is, describe how it is not what you
want.
Sending a "stealth" Cc copy
A "stealth Cc" is when you both email and post a reply without
indicating *in the body* that you are doing so.
Be extra cautious when you get upset
Count to ten before composing a followup when you are upset
This is recommended in all Usenet newsgroups. Here in clpmisc, most
flaming sub-threads are not about any feature of Perl at all! They
are most often for what was seen as a breach of netiquette. If you
have lurked for a bit, then you will know what is expected and won't
make such posts in the first place.
But if you get upset, wait a while before writing your followup. I
recommend waiting at least 30 minutes.
Count to ten after composing and before posting when you are upset
After you have written your followup, wait *another* 30 minutes
before committing yourself by posting it. You cannot take it back
once it has been said.
AUTHOR
Tad McClellan and many others on the comp.lang.perl.misc newsgroup.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
------------------------------
Date: Mon, 11 Jan 2010 12:28:40 -0800
From: sln@netherlands.com
Subject: Re: significant figures
Message-Id: <3ivmk5dc3e9u60niqen038orhi1kobg0pq@4ax.com>
On Wed, 6 Jan 2010 12:52:51 -0800, John Stanley <stanley@peak.org> wrote:
>
>On Wed, 6 Jan 2010, Ben Morrow wrote:
>> Quoth dan <spam.meplease@ntlworld.com>:
>>> 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
------------------------------
Date: Mon, 11 Jan 2010 20:10:45 -0800
From: John Stanley <stanley@peak.org>
Subject: Re: significant figures
Message-Id: <alpine.LRH.2.00.1001111922370.31371@shell.peak.org>
On Mon, 11 Jan 2010, sln@netherlands.com wrote:
> On Wed, 6 Jan 2010 12:52:51 -0800, John Stanley <stanley@peak.org> 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 = "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.
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.
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.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 2764
***************************************
