[27164] in Perl-Users-Digest
Perl-Users Digest, Issue: 8999 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Feb 27 14:05:53 2006
Date: Mon, 27 Feb 2006 11:05:05 -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 Mon, 27 Feb 2006 Volume: 10 Number: 8999
Today's topics:
Re: A Problem With GD <markem@airmail.net>
Re: A Problem With GD <markem@airmail.net>
Re: A Problem With GD <tadmc@augustmail.com>
Re: A Problem With GD <christoph.lamprecht.no.spam@web.de>
Re: A Problem With GD <christoph.lamprecht.no.spam@web.de>
Re: Decimal equality question (Anno Siegel)
Re: References as Hash Keys (Newbie) (Was: simple point <tassilo.von.parseval@rwth-aachen.de>
Re: References as Hash Keys (Newbie) (Was: simple point (Anno Siegel)
Re: References as Hash Keys (Newbie) (Was: simple point xhoster@gmail.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 27 Feb 2006 07:44:59 -0600
From: Mark Manning <markem@airmail.net>
Subject: Re: A Problem With GD
Message-Id: <12060gm2n1as8c3@corp.supernews.com>
Yes I do and like others - you are assuming things that are incorrect.
Tad McClellan wrote:
> [ text rearranged into a sensible order ]
> Then you do not know how scoring newsreaders work.
>
>
------------------------------
Date: Mon, 27 Feb 2006 08:30:23 -0600
From: Mark Manning <markem@airmail.net>
Subject: Re: A Problem With GD
Message-Id: <120635qmka1si39@corp.supernews.com>
Uri Guttman wrote:
> he insulted your code, not you. seems you have major difficulties
> separating those two. see a professional therapist to help you overcome
> your identity crisis. you are not your code. code posted here is open
> for review no matter how or who wrote it. didn't you see the sign on the
> door when you came int?
Yes he did - but >I< did not ask him to.
> you haven't traded insults with anyone. you have acted like a jerk
> defending your bad code. as of conforming, that isn't the
> issue. awareness of code quality it. but your blind eye won't see that
> so you take code review as a personal insult. bad to be you and worse to
> be your code.
Again, it was TEST CODE. An example. It was never meant to be some
super-duper, ass kissing, way of doing something. It was just some
thrown together code.
But the real problem is - why didn't Mr. Unur focus on fixing the
problem? He has absolutely no way of knowing who I am or what I do yet
he made snide comments that I feel are unbecoming of someone who
professes to offer their help. Do you REALLY think offering up
criticisms is a great way to go about helping someone? Do you call a
help desk expecting them to say if you'd only conform to how they think
you're supposed to be life would be better? Or do you expect them to
just say "Here's where the problem is"?
Therefore, the problem isn't that I took insult from his rudeness. It
is that I am standing up to him and you think he's right. Which tells
me a lot about your mental unwellness. You like the fact that he is
bullying others into submission. You must also like to lord it over
others. To act like the street gang mob boss. Do as I say or I'll do
something nasty to you. Well - too bad. He's wrong. You're wrong. It
is wrong to bully others into doing something they don't want to do. It
is wrong to make snide comments about something a program has done to
some code. I had no idea that it was going to wrap the code yet he
ASSUMED that I had done it on purpose. And you do know what assumed
means don't you? It makes an ASS out of YOU and ME.
> well consider your code to be a square peg and there is a round hole in
> your head. have fun trying to plug up the hole.
Yeah.....right.
>
> >> your humble perl code review servant,
>
> MM> Sure you are....
>
> well ok, i ain't so humble! but i do review a lot of perl code. and i
> did find a bug in your posted code caused by your poor coding style. you
> still haven't seen that and i bet it is causing problems.
Nope. No problems. The program now works great. Thank you very much.
There is a problem in the colorAllocate routine which causes it to
over write a section of the image. Once started, the more you do things
with the image - the more dots get written to the image. So ha! back to
ya boyo!
> bye bye and don't ever darken our towels again!
>
> uri
Ah! The aggrandizement of one's self! To act as if you own Usenet all
by yourself. See? This is the over inflated ego I'm talking about and
here is the pin prick to wake you up. I post when and where I please.
Which, granted, isn't a whole lot because I keep running into this same
"We own Usenet!" attitude and then I have to bust some bubbles. It gets
very tiring. All for the sake of just reporting a bug. Sheesh.
. . . . . . . . . . . .
Now. With all of that said.
Yes. You do review a lot of perl code.
------------------------------
Date: Mon, 27 Feb 2006 09:59:06 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: A Problem With GD
Message-Id: <slrne068ea.5vd.tadmc@magna.augustmail.com>
Mark Manning <markem@airmail.net> wrote:
> Uri Guttman wrote:
>
>> he insulted your code, not you.
>> you are not your code. code posted here is open
>> for review no matter how or who wrote it.
> Yes he did - but >I< did not ask him to.
That's how Usenet works. Stuff is posted, then it is commented on.
There is no requirement that the comment correspond with what
the poster wants to be commented on.
Maybe the resulting discussion addresses the OP's problem,
or maybe it doesn't.
The newsgroup does not exist to serve you, it exists to serve
the community.
> Again, it was TEST CODE. An example. It was never meant to be some
> super-duper, ass kissing, way of doing something.
Being disingenuous like that weakens your argument.
Observing the basics such as pragmas and indenting is hardly
super-duperizing things.
It is seen here as basic common courtesy.
> It was just some
> thrown together code.
Errr, yes, we could all tell.
> But the real problem is - why didn't Mr. Unur focus on fixing the
> problem?
Gee, I don't know...
Do you think maybe it was because it was just some thrown together code?
Duh!
If you are not willing to invest a little bit in making it
easier to help you solve your problem, then it is unreasonable
to expect volunteers to invest in it.
Mr. Unur focused on solving _that_ problem, which would help
you with getting answers both now and in the future.
He was being meta-helpful, that is, helping with an issue
bigger than the issue that brought you here.
(not to you, as you seem immune to social pressures, but to
many others reading this thread.
)
> Do you call a
> help desk expecting them to say if you'd only conform to how they think
There is the root cause of the group's problem with your posts.
This newsgroup is NOT A HELP DESK!
The social dynamic is very different from a help desk.
> just say "Here's where the problem is"?
Here's where the problem is:
You think that newsgroups are help desks.
> To act as if you own Usenet all
> by yourself.
That is a bizarre statement.
This society (newsgroup) has rules about what is socially acceptable.
It is *you* who are acting as if you own Usenet by flat-out
refusing to do things in a socially acceptable manner, and
attempting to change all of us to conform to "your way".
That is why there are several folks on one side of this issue
an just one person on the other side.
It is easier to join us than to fight us.
Just format code for human consumption, and ask the machine for
help before asking hundreds of live humans for help. It isn't
much to ask.
> See?
See?
> This is the over inflated ego I'm talking about
That is the over inflated ego that everyone else in this
thread is talking about.
> I post when and where I please.
That is the over inflated ego that everyone else in this
thread is talking about.
If you take cuts in line, then don't whine when someone
calls you on it.
> Which, granted, isn't a whole lot because I keep running into this same
> "We own Usenet!" attitude
It is a response to your "I own Usenet!" attitude.
Try acting like a member of a society, and see if the society's
reaction isn't different.
> very tiring.
Indeed.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Mon, 27 Feb 2006 19:25:04 +0100
From: Ch Lamprecht <christoph.lamprecht.no.spam@web.de>
Subject: Re: A Problem With GD
Message-Id: <dtvg60$s6c$1@online.de>
Mark Manning wrote:
> There is a problem in the colorAllocate routine which causes it to over
> write a section of the image.
Sorry, but that's not true.
Christoph
--
perl -e "print scalar reverse q/ed.enilno@ergn.l.hc/"
------------------------------
Date: Mon, 27 Feb 2006 19:29:16 +0100
From: Ch Lamprecht <christoph.lamprecht.no.spam@web.de>
Subject: Re: A Problem With GD
Message-Id: <dtvgds$s6c$2@online.de>
Mark Manning wrote:
>
> To clarify for everyone else - here is the answer:
>
> 1. Remove all of the colorAllocate lines.
> 2. Replace them with:
>
> $rgb = ($fg_r << 16) | ($fg_g << 8) | $fg_b;
>
> That is the answer and look!
so look:
use GD;
use warnings;
use strict;
GD::Image->trueColor(1);
my ($fg, $bg, $x, $y, $i);
my $b = new GD::Image( 100, 100 );
my $fg_r = 168;
my $fg_g = 153;
my $fg_b = 153;
my $bg_r = 136;
my $bg_g = 117;
my $bg_b = 117;
$fg = ($fg_r << 16) | ($fg_g << 8) | $fg_b;
$bg = ($bg_r << 16) | ($bg_g << 8) | $bg_b;
$b->filledRectangle( 0, 0, 99, 99, $fg );
for( $i=0; $i<500; $i++ ){
$x = int(rand(100));
$y = int(rand(100));
$b->setPixel($x, $y, $bg);
}
open( OUTFILE, ">TestPic2.png" ) || die $!;
binmode OUTFILE;
print OUTFILE $b->png;
close( OUTFILE );
open( OUTFILE, ">TestPic2.gif" ) || die $!;
binmode OUTFILE;
print OUTFILE $b->gif;
close( OUTFILE );
exit( 0 );
--
perl -e "print scalar reverse q/ed.enilno@ergn.l.hc/"
------------------------------
Date: 27 Feb 2006 11:33:49 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Decimal equality question
Message-Id: <dtuo2t$irf$2@mamenchi.zrz.TU-Berlin.DE>
a <a-no-spam@.invalid> wrote in comp.lang.perl.misc:
> this is probably a dumb question, but i'm not seeing why perl is treating
> these numbers as unequal. i've tried on a few different machines (intel and
> sparc) and perl versions (5.8.7, 5.8.3) and get the same result.
>
> perl -e 'if (361.35 == (72.27*5)) { print "EQUAL"; } else {print "NOT EQUAL";}'
The diagnosis (limited accuracy) and cure (use an epsilon in comparison)
have been given elsewhere in this thread.
Instead of explicitly choosing an epsilon, you can use Perl's internal
rounding to trim off extra precision:
perl -e 'if (361.35 eq (72.27*5)) { print "EQUAL"; } else {print "NOT EQUAL"'
That prints "EQUAL".
Using string comparison on the numbers effectively rounds the numbers
to an implementation-dependent number of places. In effect, you are
comparing with an epsilon of 0.5 times the least significant digit.
"When they print the same, they are the same"
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: Mon, 27 Feb 2006 12:14:21 +0100
From: "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de>
Subject: Re: References as Hash Keys (Newbie) (Was: simple pointer operations (newbe))
Message-Id: <46g58fFarcm3U1@news.dfncis.de>
Also sprach Veli-Pekka Tätilä:
> I do realize Perl is not the same as Java, far from it. Still browsing the
> docs for the hashCode method for the Object class, I noticed this contract
> for hashing which might be widely applicable. Quoting JDK 5.0:
[...]
> - If two objects are equal according to the equals(Object) method, then
> calling the hashCode method on each of the two objects must produce the same
> integer result.
>
> - It is not required that if two objects are unequal according to the
> equals(java.lang.Object) method, then calling the hashCode method on each of
> the two objects must produce distinct integer results. However, the
> programmer should be aware that producing distinct integer results for
> unequal objects may improve the performance of hashtables.
>
> Hmmm don't these last two statements contradict each other? At least on an
> initial read, the first seems to say that if two objects of the same Class
> return the same boolean for equals, you must return the same hash codes.
> However, the second one effectively mitigates the first by saying that if
> they produce different boolean values for equals, they don't have to produce
> different hashcodes. So as far as I can see, you cannot tell based on the
> hash code whether two objects are equal. The hash codes can be the same if
> they are and they can still be the same if they aren't. What's the use of
> being able to use objects as hash keys then? Perhaps I'm again missing
> something fundamental here.
You are blurring the distinction between the key that is to be hashed
and the result of this hashing, namely the hash code.
You can build a hash where all keys are projected onto the same hash
code and yet the hash remains functional. This is just going to be a
terribly inefficient hash as each new key inserted produces a collision.
Think of a hash as an array where a key/value pair is stored inside one
of the array's element. Which element is going to be used is determined
by the hash code. If a collision occurs because two different keys
produce the same hash code, then some method of resolving this collision
must be used. Usually, the array's elements are linked lists so that on
each collision a new pair is pushed onto this list.
A simple hash implemented in Perl would look like this:
package Hash;
use constant HASH_SEED => 1;
sub hash {
my ($self, $key) = @_;
my $hc = HASH_SEED;
$hc ^= ord $_ for split //, $key;
return $hc % @$self;
}
sub new {
my ($class, $size) = @_;
my @ary; $#ary = ($size || 4) - 1;
return bless \@ary => $class;
}
sub store {
my ($self, $key, $value) = @_;
my $code = $self->hash($key);
# collision: check if key is already in hash
if ($self->[$code]) {
for (@{ $self->[$code] }) {
if ($_->{key} eq $key) {
# key in the hash: update value
$_->{val} = $value;
return;
}
}
}
# not yet in the hash
push @{ $self->[$code] }, { key => $key, val => $value };
}
sub get {
my ($self, $key) = @_;
my $code = $self->hash($key);
return if ! $self->[$code];
for (@{ $self->[$code] }) {
return $_->{val} if $_->{key} eq $key;
}
}
It's not terribly smart as the array for the key/value pairs is never
resized so the more elements you put in the slower it will get. And you
can now use a hash with only two buckets and yet store an arbitrary
amount of key/value pairs in them:
use Data::Dumper;
my $hash = Hash->new(2);
my $c = 0;
for (qw/foo bar 123 bla 567/) {
$hash->store($_, $c++);
}
for (qw/foo bar 123 bla 567/) {
print $hash->get($_), "\n";
}
print Dumper $hash;
__END__
foo => 0
bar => 1
123 => 2
bla => 3
567 => 4
$VAR1 = bless( [
[
{
'val' => 1,
'key' => 'bar'
},
{
'val' => 3,
'key' => 'bla'
}
],
[
{
'val' => 0,
'key' => 'foo'
},
{
'val' => 2,
'key' => '123'
},
{
'val' => 4,
'key' => '567'
}
]
], 'Hash' );
As you can see, the keys 'foo', '123' and '567' all had the same hash code
which is why they ended up in the same array element.
This also explains why it is more efficient to have two different keys
have two different hash codes. When they have the same hash code, a
collision happens and a linear list of key/value pairs first has to be
searched to find the right pair.
Tassilo
--
use bigint;
$n=71423350343770280161397026330337371139054411854220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
------------------------------
Date: 27 Feb 2006 13:24:32 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: References as Hash Keys (Newbie) (Was: simple pointer operations (newbe))
Message-Id: <dtuuig$ntj$1@mamenchi.zrz.TU-Berlin.DE>
Veli-Pekka Tätilä <vtatila@mail.student.oulu.fi> wrote in comp.lang.perl.misc:
> Anno Siegel wrote:
> <snip>
> > It is true that a string comparison of two references is true if and only
> > if the references are the same.
> I thought so, too, when stringification enters the picture they can be equal
> only when their types and addresses are exactly the same. But still, hmm,
> you cannot have references to two different types pointing to the same
> memory address, of course, so on second thought the address is a unique key
> alone.
>
> > The strings that are compared may not be the same each time.
> Is this because of possible garbage collection, or scalars growing or
> shrinking automagically?
No. Nothing that happens internally, except cloning at the start of
a new thread, changes the reference address of a Perl value.
If you bless a reference, the string associated with it will contain
the class name. Since a reference can be unblessd, then blessed into
one class, then into another over its lifetime, the way it stringifies
may change.
> Hmm speaking of hash keys, my understanding based
> on some other languages is that they must depend on the object's state to be
> able to work consistantly.
You're digging too deep. Tassilo has explained very well the difference
in hash keys (strings) and the hash value (an integer) used internally.
We're only talking hash keys here.
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: 27 Feb 2006 18:14:49 GMT
From: xhoster@gmail.com
Subject: Re: References as Hash Keys (Newbie) (Was: simple pointer operations (newbe))
Message-Id: <20060227131814.626$7e@newsreader.com>
"Veli-Pekka Tätilä" <vtatila@mail.student.oulu.fi> wrote:
> Anno Siegel wrote:
> <snip>
> > It is true that a string comparison of two references is true if and
> > only if the references are the same.
> I thought so, too, when stringification enters the picture they can be
> equal only when their types and addresses are exactly the same. But
> still, hmm, you cannot have references to two different types pointing to
> the same memory address, of course, so on second thought the address is a
> unique key alone.
You can, if at least one of the referenced variables is no longer alive.
Then the address can be reused.
> Hmm speaking of hash keys, my understanding
> based on some other languages is that they must depend on the object's
> state to be able to work consistantly.
They do not need to depend on the object's state. In fact, I would
say they even cannot depend on the object's state, depending on what you
want to use them for.
> But if you use a stringified
> memory address and the address changes later on independent of the
> blessed thing's state, you cannot just dereference the same blessed
> thingy to reuse it as a key in indexing.
You don't dereference thingies to use them as a key, you stringify them.
> Many other languages let you
> freely use objects or whatever else you like as hash keys. ARe there any
> workarounds for Perl? One possibility that came to mind would be to use
> Data::Dumper and compute a hash value based on the object's state. Can I
> somehow access Perl's internal hashing function for keys to hash my own
> data, similar to Java's hashCode method?
There is nothing to prevent you from defining a method named hashCode on
each of your classes in Perl. You could even probably make a module,
something like Tie::RefHash, that would invoke this method for you when
appropriate.
> I do realize Perl is not the same as Java, far from it. Still browsing
> the docs for the hashCode method for the Object class, I noticed this
> contract for hashing which might be widely applicable. Quoting JDK 5.0:
>
> - Whenever it is invoked on the same object more than once during an
> execution of a Java application, the hashCode method must consistently
> return the same integer, provided no information used in equals
> comparisons on the object is modified. This integer need not remain
> consistent from one execution of an application to another execution of
> the same application.
>
> Interesting, so the internal state may change and you're allowed to
> return the same hash code as long as the equality of the object, as far
> as the user goes, is not altered. Maybe my suggestion about simply
> dumping the blessed thingy's internals isn't wise after all.
Depends on your intended to use.
>
> - If two objects are equal according to the equals(Object) method, then
> calling the hashCode method on each of the two objects must produce the
> same integer result.
>
> - It is not required that if two objects are unequal according to the
> equals(java.lang.Object) method, then calling the hashCode method on each
> of the two objects must produce distinct integer results. However, the
> programmer should be aware that producing distinct integer results for
> unequal objects may improve the performance of hashtables.
>
> Hmmm don't these last two statements contradict each other?
No. I believe you have fallen into the fallacy of affirming the
consequent, or maybe it is denying the antecedent, or something akin to
them.
> At least on
> an initial read, the first seems to say that if two objects of the same
> Class return the same boolean for equals, you must return the same hash
> codes. However, the second one effectively mitigates the first by saying
> that if they produce different boolean values for equals, they don't have
> to produce different hashcodes. So as far as I can see, you cannot tell
> based on the hash code whether two objects are equal. The hash codes can
> be the same if they are and they can still be the same if they aren't.
> What's the use of being able to use objects as hash keys then?
Performance.
> Perhaps
> I'm again missing something fundamental here.
Yes. You are missing the fact that calling query.equals on the ten objects
which happen to have the same hashcode as the query is a heck of a lot
faster than calling query.equals on the ten object with the same hash code
plus the 398_931 other objects in the hash table which do not have the same
hash code.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
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 V10 Issue 8999
***************************************
