[30514] in Perl-Users-Digest
Perl-Users Digest, Issue: 1757 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jul 31 16:09:43 2008
Date: Thu, 31 Jul 2008 13:09:09 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 31 Jul 2008 Volume: 11 Number: 1757
Today's topics:
&& is not an lvalue xhoster@gmail.com
Re: Extracting bits out of huge numbers <blabla@dungeon.de>
Re: Extracting bits out of huge numbers <blabla@dungeon.de>
Re: Extracting bits out of huge numbers <blabla@dungeon.de>
Re: Extracting bits out of huge numbers <bugbear@trim_papermule.co.uk_trim>
Re: Extracting bits out of huge numbers <ben@morrow.me.uk>
Re: FAQ 4.2 Why is int() broken? <szrRE@szromanMO.comVE>
Re: FAQ 4.2 Why is int() broken? <szrRE@szromanMO.comVE>
Re: Logging with Log::StdLog from within a package <ben@morrow.me.uk>
Re: Logging with Log::StdLog from within a package <jerry@ieee.org>
Re: Logging with Log::StdLog from within a package <ben@morrow.me.uk>
Re: Question about variable scope <sbryce@scottbryce.com>
Re: questions on XML::Simple xhoster@gmail.com
Re: what is the expression mean? <jurgenex@hotmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 31 Jul 2008 19:14:06 GMT
From: xhoster@gmail.com
Subject: && is not an lvalue
Message-Id: <20080731151408.267$0N@newsreader.com>
It seems like almost everything in Perl is an lvalue. So why isn't the
result of && an lvalue?
I wanted to do this:
($h{$big}{$nasty}[$dereferencing]{operation($x)}{$done}[here(y)]and die)=6;
Obviously, that just isn't the way perl was implemented. But is there a
reason that "?:" yields an lvalue but && doesn't?
Thanks,
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Thu, 31 Jul 2008 02:34:37 -0700 (PDT)
From: hofer <blabla@dungeon.de>
Subject: Re: Extracting bits out of huge numbers
Message-Id: <683a0380-6917-4895-a4d3-43d82e237bc2@m3g2000hsc.googlegroups.com>
On Jul 30, 1:23 am, "Thrill5" <nos...@somewhere.com> wrote:
> "hofer" <bla...@dungeon.de> wrote in message
>
> news:ce050ae4-9a3f-406d-b9f1-52a19754e37d@z66g2000hsc.googlegroups.com...
>
>
>
> > Hi,
>
> > I'd like to work with huge integers (> 64 bit precision)
>
> > Thus I can't use ordinary perl integers.
>
> > I thought Math::BigInt wouldn't be a too bad choice.
>
> > It's easy enough go create BigInts.
> > my $a = Math::BigInt->new("0x7777666655544443333222211110000");
> > my $b = Math::BigInt->new("0x1111111111111111111111111111111");
>
> > Calculating with them is also fine:
> > $a->badd($b); # $a = $a + $b
>
> > Now I would like to extract certain bits out of this huge number:
>
> > Example Bits 16 bis 12 should result in 0b00001 == 0x1 == 1
> > Bits 17 bis 12 should result in 0b100001 == 0x21 == 33
>
> > So far I see two ways of doing this conversion.
>
> > However I'm not really appealed by either solution.
>
> > Do you know anything faster / better or even another CPAN module?
>
> > # extract bits out of binary string
> > sub extbits { #
> > my ($val,$msb,$lsb) = @_; # $val must be Math::BigInt;
> > my $asbinstr = $val->as_bin(); # nun als binaer string
> > my $withoutprefix = substr($asbinstr,2); # fuehrendes '0b'
> > entfernen
> > my $substr = substr($withoutprefix,-$msb-1,$msb-$lsb+1); # den
> > substring extrahieren
> > $substr = 0 if $substr eq ""; # sollte mindestens einen character
> > enthalten
> > my $result = Mat::BigInt->new("0b".$substr); # zurueck in
> > Math::BigInt verwandeln
> > return $result;
> > } #
>
> > # extract bits via shifts operations follwed by a bit wise and
> > sub extbits { #/*{{{*/
> > my ($val,$msb,$lsb) = @_; # $val must be Math::BigInt;
> > my $mask = Math::BigInt->new(1); # create a 1
> > $mask->blsft($msb-$lsb+1); # 2 ^ (number of bits to extract)
> > $mask->bsub(1); # now we have a mask
> > my $tmp = $val->copy->brsft($lsb); # shift input value to the
> > right
> > return $tmp->band($mask);
> > } #/*}}}*/
>
> > Thanks in advance for any other suggestions
> > like rewriting the function to accelerate it or using another module.
>
> > bye
>
> > H
>
> How about using 'unpack'?
Hi, Thrill5,
Thanks for the answer.
If I don't miss something, then pack and unpack allow to (hmmm) pack
and
unpack binary strings into a byte structure.
My second requirement is to perform operations like + - * / and or xor
% on these numbers.
I think this wouldn't be possible.
bye
H
------------------------------
Date: Thu, 31 Jul 2008 02:36:21 -0700 (PDT)
From: hofer <blabla@dungeon.de>
Subject: Re: Extracting bits out of huge numbers
Message-Id: <f24180dc-de6f-412e-b3dd-4825fb474b5f@d45g2000hsc.googlegroups.com>
Hi sisiphus,
I'll look at Math::GMP
In the doc I saw an interesting suggestion, which is to use
Math::BigInt, but let it use the faster libraries of Math::GMP.
This means probably, that I would run faste, but would stay backwards
compatible for the ones not having Math::GMP.
The suggested use statement is:
use Math::BigInt lib => 'GMP';
The function Math::GMP::gmp_tstbit() sounds very appealing to test a
few
bits of a big number.
However if I want to extract for example bits [967:13] , then the
approach to shift to the right and logical and then with a mask might
be
faster.
I have to try.
thanks and bye
H
On Jul 30, 4:12 am, sisyphus <sisyphus...@gmail.com> wrote:
> On Jul 29, 10:28 pm, hofer <bla...@dungeon.de> wrote:
>
>
>
> > Hi,
>
> > I'd like to work with huge integers (> 64 bit precision)
>
> > Thus I can't use ordinary perl integers.
>
> > I thought Math::BigInt wouldn't be a too bad choice.
>
> > It's easy enough go create BigInts.
> > my $a = Math::BigInt->new("0x7777666655544443333222211110000");
> > my $b = Math::BigInt->new("0x1111111111111111111111111111111");
>
> > Calculating with them is also fine:
> > $a->badd($b); # $a = $a + $b
>
> > Now I would like to extract certain bits out of this huge number:
>
> > Example Bits 16 bis 12 should result in 0b00001 == 0x1 == 1
> > Bits 17 bis 12 should result in 0b100001 == 0x21 == 33
>
> > So far I see two ways of doing this conversion.
>
> > However I'm not really appealed by either solution.
>
> > Do you know anything faster / better or even another CPAN module?
>
> Math::GMP will allow you to access individual bits. I would expect it
> to be siginificantly faster than Math::BigInt, though I haven't done
> any benchmarking.
>
> use warnings;
> use Math::GMP;
>
> $x = Math::GMP->new('12344' x 7);
>
> # print the 10 least siginificant bits:
>
> print Math::GMP::gmp_tstbit($x, $_) for reverse(0..9);
> print "\n";
>
> Cheers,
> Rob
------------------------------
Date: Thu, 31 Jul 2008 02:40:10 -0700 (PDT)
From: hofer <blabla@dungeon.de>
Subject: Re: Extracting bits out of huge numbers
Message-Id: <8b7cb0e9-a3cd-4869-a8fb-cd87c8f75c8c@y21g2000hsf.googlegroups.com>
Hi Bugbear,
I'm not that gifted in explaining, but I t'll try.
First if your question concerns the representation of binary numbers:
Then look at http://en.wikipedia.org/wiki/Binary_numeral_system
Second:
ust a small example however just with 8 bit numbers.
Please keep in mind, that I really want to work with really big
numbers.
well an unsigned 8 bit number can have values from
0 to 255
The number 26 for example would be represented as
00011010 in binary format
For small numbers I could just use
printf("%08b",26) to get the binary string
# result should be 00011010
going from binary string representation to decimal could be done with
the oct() function
I just have to prefix the bit string with "0b" and pass it to the
oct() function.
print oct("0b"."00011010");
# result shoud be 26
the bits of this number are number from right to left so the bt on the
right is bit 0 and the bit on the left is bit7
the number 26
would have
bit 0 = 0
bit 1 = 1
bit 2 = 0
bit 3 = 1
bit 4 = 1
bit 5 = 0
bit 6 = 0
bit 7 = 0
if I want to extract bits 4 to bits 2 from my number 26 it would mean
taking
bit 2 = 0
bit 3 = 1
bit 4 = 1
which is 110 or 0b110 (0b marks a binary number in perl)
and would be equivalent to number 6 in decimal.
so I could do for example
$num = 26; #
$size=8; # tha value has a max size of 8 bits
$bitfrom=4;
$bitto=2;
$bitstring = sprintf("%0%sizeb",$num); # -> "00011010"
# the first character in this string is bit 7, tha last one is bit 0
so to get bits 4 to 2 I could now do
$bits4to2 = substr($bitstring,-$from,$from-$to+1); # -> "110"
$num4to2 = oct("0b".$bits4to2); # -> 6
I hope that clarified a little.
bye H
On Jul 30, 10:32 am, bugbear <bugbear@trim_papermule.co.uk_trim>
wrote:
> hofer wrote:
> > Hi,
>
> > Now I would like to extract certain bits out of this huge number:
>
> > Example Bits 16 bis 12 should result in 0b00001 == 0x1 == 1
> > Bits 17 bis 12 should result in 0b100001 == 0x21 == 33
>
> I don't understand your examples :-(
>
> BugBear
------------------------------
Date: Thu, 31 Jul 2008 11:55:54 +0100
From: bugbear <bugbear@trim_papermule.co.uk_trim>
Subject: Re: Extracting bits out of huge numbers
Message-Id: <QoSdnQQ8PsOnBwzVnZ2dneKdnZydnZ2d@posted.plusnet>
hofer wrote:
> Hi Bugbear,
>
> I'm not that gifted in explaining, but I t'll try.
>
> First if your question concerns the representation of binary numbers:
> Then look at http://en.wikipedia.org/wiki/Binary_numeral_system
I am familiar with multi precision and multi base concepts.
>>Example Bits 16 bis 12 should result in 0b00001 == 0x1 == 1
>> Bits 17 bis 12 should result in 0b100001 == 0x21 == 33
what do you mean by
"Bits 16 bis 12"
and
"Bit 17s bis 12"
what is "bis" ?
BugBear
------------------------------
Date: Thu, 31 Jul 2008 15:15:53 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Extracting bits out of huge numbers
Message-Id: <p1u8m5-gh2.ln1@osiris.mauzo.dyndns.org>
Quoth bugbear <bugbear@trim_papermule.co.uk_trim>:
> hofer wrote:
> >>
> >>Example Bits 16 bis 12 should result in 0b00001 == 0x1 == 1
> >> Bits 17 bis 12 should result in 0b100001 == 0x21 == 33
>
>
> what do you mean by
> "Bits 16 bis 12"
>
> and
>
> "Bit 17s bis 12"
>
> what is "bis" ?
'To' in English, 'through' or 'thru' in American. So, the OP wishes to
look at only the bits from bit 16 to bit 12; something like
my $num = ...;
my $mask = 0;
$mask |= 1<<$_ for 12..16;
$num &= $mask;
$num >>= 12;
would do what he wants, but slowly, and with small(ish) integers only.
Ben
--
And if you wanna make sense / Whatcha looking at me for? (Fiona Apple)
* ben@morrow.me.uk *
------------------------------
Date: Thu, 31 Jul 2008 10:04:05 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: FAQ 4.2 Why is int() broken?
Message-Id: <g6sra602lur@news4.newsguy.com>
Peter J. Holzer wrote:
> On 2008-07-29 15:57, szr <szrRE@szromanMO.comVE> wrote:
>> Peter J. Holzer wrote:
>>> On 2008-07-28 17:56, szr <szrRE@szromanMO.comVE> wrote:
>>>> Peter J. Holzer wrote:
>>>>> On 2008-07-28 06:12, Jürgen Exner <jurgenex@hotmail.com> wrote:
>>>>>> "szr" <szrRE@szromanMO.comVE> wrote:
>>>>>>> it needs just one decimal digit
>>>>>>
>>>>>> Irrelevant because your typical computer does not use decimal
>>>>>> numbers but binary numbers, just like Peter said.
>>>>>
>>>>> Actually, I didn't write what "a typical computer" uses, just what
>>>>> happens when a binary system is used (which is what perl uses on
>>>>> most (all?) platforms - COBOL uses normally uses decimal).
>>>>
>>>> Even among different types of computers floating point calculations
>>>> are not all done the same. For instance, I have a graphing
>>>> calculator, which is essentially tiny computer with a 6 MHz cpu and
>>>> yet it can do many floating point calculations more accurately than
>>>> my dual core cpu desktop.
>>>
>>> I'm not up to date with calculators (the last one I bought was an
>>> HP-48 20 years ago), but frankly, I doubt that it is more accurate.
>>> It has probably less than 15 digits of mantissa. It probably does
>>> its computations in decimal, which makes them even less accurate,
>>> but the errors *match* *your* *expectations*, so you don't notice
>>> then.
>>
>>
>> My point was, on graphing calculators I've used (which has mainly
>> consisted of Texas Instrument TI-8*'s), the results are what you'd
>> expect them to me math wise for the most part. That is, what you'd
>> expect if you were to do it using plain ol' pencil and paper.
>
> Please note the words you are using yourself: "expect" and "for the
> most part". A calcutor uses decimal arithmetic, just like you do when
> you use pencil and paper. So it will produce the correct results in
> the same cases and it will make the same errors - it will do what you
> expect. But that doesn't mean it is more accurate in general - only
> for decimal numbers.
I probably should of been more clear. Yes, in the case of calulator and
pencil paper, it's about doing calculations with decimal (or Real)
numbers.
>>>> Granted, it's a calculator, but I have often wondered why it
>>>> seems to be able to handle such calculations better than a CPU
>>>> that's over 400 times faster.
>>>
>>> Different target. Calculators can be slow - they do only primitive
>>> computations, and if they finish them in a short but noticable time
>>> its still "fast enough". A modern CPU is supposed to be able to do
>>> hundreds of millions such computations per second. Calculators are
>>> also rarely used for computations where accuracy is much of an issue
>>> - 8 or 12 digits are enough. But they are used by people who expect
>>> 0.1 * 10 to be 1.0 but aren't overly surprised if 1/3*3 is
>>> 0.9999999.
>>
>> Testing on a TI-89 (which does have a hefty amount of precision)
>> entering "1/3*3.0" yields "1." and so does "0.1*10", and Perl seems
>> to give the same results. On what hardware, language, or such, do
>> you end up getting 0.99999.. from 1/3*3.0 ?
>
> For example on my HP-48 calculator. It uses 12 decimal places, so 1/3
> is
> 0.333333333333. 0.333333333333 * 3 is clearly 0.999999999999.
A TI-86 also uses 12 decimal places. But it depens how you enter things:
1/3
.333333333333
.333333333333 * 3
.999999999999
But:
123456789012345678901
1/3
.333333333333
Ans*3
1
The 2nd example uses the build in "Ans" variable which always contains
the result of the last computation, which can be more accurate than
simply re-typing what was displayed.
what happens if you enter "(1/3) * 3" instead of "0.333333333333 * 3" on
your HP-48 ?
> I don't have my old TI-57 at hand (it's about 600 km away), but IIRC
> it used 11 decimal digits and displayed only 8. So 1/3 would be
> 0.33333333333 (displayed as 0.3333333), multiplication with 3 would
> then yield 0.99999999999 (displayed as 1). So, you see "1", but the
> error is still there. If you subtract 1.0, you will get 1E-11.
Just like with mine, theres a difference between what is known
internally and what is displayed.
> (deja vu: I had almost exactly this discussion with my room mate 22
> years ago: He claimed that his TI was more accurate than my HP because
> 1/3*3 *displayed* 1 instead of 0.999999999999. Changing the
> calculation into 1/3*3-1 showed otherwise: He got 1E-11, I got 1E-12,
> which is clearly the smaller error.)
On a TI-86, "1/3*3-1" gives me -1E14, but on a TI-89 it's 0. I have no
idea why the result is negative on the 86, unless the sign bit is
somehow being clobbered.
Mathetically, the TI-89 seems to get it more right, as (1/3)*3 = 1 is
mathematically correct, as the 3 in the demoninator in of the first
number and 3 in the numinator of the 2nd number (3/1) cancel each other
out, leaving 1/1 which is better writen as just plain ol' 1. Then 1-1
is, of course, 0.
I'm not sure why the TI-86 has such a strange result when "-1" is thrown
in, but the TI-89 doesn't have this problem, and it seems neither does
Perl:
$ perl -e 'print +(1/3), "\n";'
0.333333333333333333
$ perl -e 'print +(0.333333333333333333 * 3), "\n";'
0.999999999999999999
$ perl -e 'print +(1/3*3), "\n";'
1
$ perl -e 'print +(1/3*3-1), "\n";'
0
> For 64-bit binary floating point numbers, 1.0/3.0 is
> 0.333333333333333314829616256247390992939472198486328125
> times 3 would be
> .999999999999999944488848768742172978818416595458984375 exactly, but
> that cannot be represented in 53 bits of mantissa, so it needs to be
> rounded - up in this case, so the result is indeed 1.0 exactly. So
> here we have a case where a calculation in decimal cannot possibly
> produce the correct result, but in binary it will (only by chance,
> granted. But even if the result had been rounded down the error would
> still be only ~ 1.1E-16, quite a bit lower than on the HP-48 or
> TI-57).
>
>
>
>>> [1] Incidentally, I know of one modern processor (the IBM Power6)
>>> which implements full decimal floating point arithmetic in
>>> hardware.
>>
>> I remember back in the days of the 486 processor you had a separate
>> "Math Co-Processor",
>
> You mean the days *before* the 486 processor.
>
> The 486 was the first intel processor which had an integrated FP
> unit instead of a separate coprocessor.
I think you might be right. I pulled the box that the contains the
motherboard and other parts from it and I can't tell just by looking it
seems. There is a big square chip I certainally remember quite well: the
one with "486 DX2" nicely written upon it. It was a very powerful
computer for it's time and one I have very fond memories of in the PC
glory days :-)
>> I wonder what would happen if they reinstituted
>> that idea, but on a more powerful/modern scale?
>
> The "math coprocessor" is still there. It's just on the same chip. And
> the FP unit of a Pentium 4 is much, much more powerful than the 387
> was.
I assume s/387/386/ and you are of course right.
--
szr
------------------------------
Date: Thu, 31 Jul 2008 10:34:12 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: FAQ 4.2 Why is int() broken?
Message-Id: <g6st2l02nnq@news4.newsguy.com>
szr wrote:
> Peter J. Holzer wrote:
>> On 2008-07-29 15:57, szr <szrRE@szromanMO.comVE> wrote:
[...]
>>> I wonder what would happen if they reinstituted
>>> that idea, but on a more powerful/modern scale?
>>
>> The "math coprocessor" is still there. It's just on the same chip.
>> And the FP unit of a Pentium 4 is much, much more powerful than the
>> 387 was.
>
>
> I assume s/387/386/ and you are of course right.
Oh wait, 387 was the math co-processor.
--
szr
------------------------------
Date: Thu, 31 Jul 2008 15:06:54 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Logging with Log::StdLog from within a package
Message-Id: <ugt8m5-gh2.ln1@osiris.mauzo.dyndns.org>
Quoth Jerry Krinock <jerry@ieee.org>:
> Today, I separated out a file of functions into a separate package:
>
> package MyPackage ;
>
> Instead of 'use', I 'require and call the functions using
>
> MyPackage::aFunction() ;
>
> It works fine except for my Log::Stdlog calls such as:
>
> print {*STDLOG} info => "Hello\n" ;
>
> None of any such calls from inside package functions print to my log
> any more. They "just don't work".
Global filehandles are package scoped, so if you opened that STDLOG
filehandle in package main, then you will need
print {*main::STDLOG} info => "Hello\n";
Alternatively, you can 'use Log::StdLog' within your package MyPackage
as well (or instead); this will reopen the logfile but that shouldn't be
a problem.
> A confession: I've come a long way with Perl, but one thing still
> beyond my comprehension is the 'tie' function with its "enchanted"
> variable that seems to be the magic behind {*STDLOG}. What does the
> asterisk do?
The {* } is just Damian being paranoid :). Normally that would be
written
print STDLOG info => "Hello\n";
but if you have a sub or a package called STDLOG that statement is
ambiguous, and it's far from obvious how perl resolves that ambiguity.
print {*STDLOG} ...
is just a way of saying 'yes, I really mean the builtin 'print' and the
filehandle 'STDLOG', whatever other ideas you might have'. The fact
STDLOG is tied is not relevant here: you could just as well say
print {*STDERR} ...
if you wanted to.
Ben
--
'Deserve [death]? I daresay he did. Many live that deserve death. And some die
that deserve life. Can you give it to them? Then do not be too eager to deal
out death in judgement. For even the very wise cannot see all ends.'
ben@morrow.me.uk
------------------------------
Date: Thu, 31 Jul 2008 10:20:57 -0700 (PDT)
From: Jerry Krinock <jerry@ieee.org>
Subject: Re: Logging with Log::StdLog from within a package
Message-Id: <7ef91908-aead-4de5-9f09-45c3edc8703a@l64g2000hse.googlegroups.com>
Thank you, Ben. I used {*::STDLOG} and it works now.
But what is that {*FILEHANDLE} syntax mean to the perl interpreter? I
thought that there is no "*" operator in perl, and {} is used for code
blocks or hash assignments. Which, if any, perldoc?
Jerry
------------------------------
Date: Thu, 31 Jul 2008 19:36:55 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Logging with Log::StdLog from within a package
Message-Id: <7bd9m5-75e.ln1@osiris.mauzo.dyndns.org>
Quoth Jerry Krinock <jerry@ieee.org>:
> Thank you, Ben. I used {*::STDLOG} and it works now.
>
> But what is that {*FILEHANDLE} syntax mean to the perl interpreter? I
> thought that there is no "*" operator in perl, and {} is used for code
> blocks or hash assignments. Which, if any, perldoc?
*FOO is described in perldata, under 'Typeglobs and Filehandles', and
further elaborated on in perlmod. The print {...} syntax is documented
in perldoc -f print; it applies quite generally to any builtin or method
call that has an 'indirect object' slot. The block is required if you
want to put anything more complicated that a simple scalar there.
Ben
--
"If a book is worth reading when you are six, * ben@morrow.me.uk
it is worth reading when you are sixty." [C.S.Lewis]
------------------------------
Date: Thu, 31 Jul 2008 02:38:21 -0600
From: Scott Bryce <sbryce@scottbryce.com>
Subject: Re: Question about variable scope
Message-Id: <9NadnRXnaPlj5AzVnZ2dnUVZ_gKdnZ2d@comcast.com>
John W. Krahn wrote:
> nospam wrote:
>> # $nntp = Net::NNTP->new($newshost);
>
> Here $nntp is a package variable and is visible anywhere inside the
> current package. Even if you had used a lexical variable it would be
> visible anywhere after this point in the program.
The line of code in question is commented out. $nntp is not a variable,
but part of a comment.
The OP should read the posting guidelines for this group and try asking
the question again.
------------------------------
Date: 31 Jul 2008 16:49:46 GMT
From: xhoster@gmail.com
Subject: Re: questions on XML::Simple
Message-Id: <20080731124947.918$eQ@newsreader.com>
Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth Jeff <dreamgear@gmail.com>:
> > I used the XML::Simple module to read some xml, which works great.
> >
> > But when I write it back out with XMLout.. it's changed.
> >
> > For example the input that looks like this:
> >
> > <Summary>
> > <TotalOrders>1</TotalOrders>
> > <TotalLineItems>4</TotalLineItems>
> > <TotalQuantity>158</TotalQuantity>
> > </Summary>
> >
> > ends up looking like this:
> >
> > <Summary TotalLineItems="4" TotalOrders="1" TotalQuantity="158" />
> >
> >
> > Is it possible to have it written out in the same format it was read
> > from?
>
> See the NoAttr option.
Use ForceArray when doing XMLin. I think this would be better than
using NoAttr on XMLout. With ForceArray things that were attributes on the
way in are still attributes on the way out, while tags on the way in are
tags on the way out--rather than turning everything into tags.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Thu, 31 Jul 2008 07:55:26 GMT
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: what is the expression mean?
Message-Id: <1jr294daje0td6k8lu9did650lg0502gpa@4ax.com>
Michael Carman <mjcarman@mchsi.com> wrote:
>Nathan wrote:
>> The B<> and C<> tags really look confusing!
>
>perldoc perlpod
That may explain what they are but it doesn't stop making them look
confusing. I agree with Nathan and would prefer standard Usenet
conventions, like e.g. using underscore characters to add emphasis or
putting actual code in a line of its own if there is a risk of confusing
code and text.
jue
------------------------------
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:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#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 1757
***************************************
