From doug.miles at bpxinternet.com Wed Aug 1 12:53:13 2001 From: doug.miles at bpxinternet.com (Doug Miles) Date: Thu Aug 5 00:16:28 2004 Subject: Phoenix.pm: Meeting 08/02/2001 References: Message-ID: <3B684209.70604@bpxinternet.com> Scott Walters wrote: > I would *love* a first hand report, and I for one wouldn't mind a talk > on SelfGOL (sinse I'll prolly never have the chance to see Damian > present it himself). > > -s I second this! Rob, would you be able to present this next time? > > On Tue, 31 Jul 2001, Svirskas Rob-ERS007 wrote: > > >> I won't be able to make it this week, but if anyone's interested in the five days of madness and mayhem commonly referred to as the "O'Reilly Open Source Convention", I can give a brief on it next meeting. I'm still recovering from Damian Conway's talk on "SelfGOL", a 999-byte viral quine that also manages to animate banner text and play Conway's "Game of Life". >> - Rob >> >> -----Original Message----- >> From: Scott Walters [mailto:phaedrus@contactdesigns.com] >> Sent: Tuesday, July 31, 2001 1:33 PM >> To: Phoenix.pm >> Subject: Re: Phoenix.pm: Meeting 08/02/2001 >> >> >> First post!!! >> (Sorry, my IQ is attached to the LA power grid. It kinda goes up >> and down throughout the day...) >> >> For some time in the future, I've got a couple of small apps >> I can present... Yes, I take requests, and require motivation =) >> >> 1) Poll booth software that allows users to place multiple votes, >> and divides their single vote into "virtual" smaller votes. >> [To do - instant run-offs, then I can sell it to the US gov't]. >> >> 2) Mail sorting, indexing, uniquifing software with a hand full >> of indexes and reports. >> >> 3) "How to" for desinging credit card gateway clients (all banks >> are basicly the same but each different and undocumented). >> >> 4) An expandy-contracty-thing for drilling down within a document. >> >> 5) Perl interface to the Linux module that loads new microcode >> into Intel PIII chips >> >> 6) I'm at the library right now looking at sime simple fuzzy logic >> software in C that I could be persuaded to translate to Perl >> >> 7) Braindead webserver in Perl (about 60 lines long, don't remember). >> >> One of those is a decoy, but I'm curious to see if anyone asks for it =) >> Mind you, this is only if no one has anything... >> >> [trying this again, first attempt seems to have got lost.. email doesnt >> work for me] >> >> -scott >> >> >> >> >> >> On Tue, 31 Jul 2001, Doug Miles wrote: >> >> >>> We'll be having a Phoenix.pm meeting Thursday August 2nd at 7:00PM. >>> It will be held at The Willow House, which is located at 149 W. McDowell >>> Rd., which is just West of Bowne on McDowell. This is a social meeting, >>> so just show up, hang out, and have fun. The Willow House has coffee, >>> and sandwiches, so bring some money if you are hungry. If you want more >>> information, visit http://www.willowhouse.com/. See you there! >>> >>> -- >>> For a list of the ways which technology has failed >>> to improve our quality of life, press 3. >>> >>> >> From whitneyt at agcs.com Wed Aug 1 14:31:56 2001 From: whitneyt at agcs.com (Thomas Whitney) Date: Thu Aug 5 00:16:28 2004 Subject: Phoenix.pm: Math References: <3B684209.70604@bpxinternet.com> Message-ID: <3B68592C.AF8E0B8A@agcs.com> Hi All, I am doing a lot of decimal arithmetic. I ran into problems using perl's standard arithmetic. Right now I am using Math::BigFloat, but it seems slow. Can anybody recommend a better module Thanks Tom From phaedrus at contactdesigns.com Wed Aug 1 11:45:43 2001 From: phaedrus at contactdesigns.com (Scott Walters) Date: Thu Aug 5 00:16:28 2004 Subject: Phoenix.pm: Math In-Reply-To: <3B68592C.AF8E0B8A@agcs.com> Message-ID: Hey Tom, Well, looking at Math::BigInt/BigFloat, they do everything in Perl by unpacking into an array from a string... something in C or Perl that minipulated it directly in its binary format would be much faster... what problems were you having with perls built in operators? Overflow? Precision? Don't know of anything offhand, and I assume you've searched CPAN... If you wanted to use a C library, Doug just did a demo on [what was that?] Embed, which makes it really easy to stick some C right in middle of your Perl. -scott On Wed, 1 Aug 2001, Thomas Whitney wrote: > Hi All, > > I am doing a lot of decimal arithmetic. I ran into problems using perl's standard arithmetic. Right now I am using Math::BigFloat, but it seems slow. Can anybody recommend a better module > > Thanks > Tom > > From Rob.Svirskas at motorola.com Wed Aug 1 15:12:12 2001 From: Rob.Svirskas at motorola.com (Svirskas Rob-ERS007) Date: Thu Aug 5 00:16:28 2004 Subject: Phoenix.pm: Math Message-ID: <07077F6C2A38D511920800D0B7821B322A44BD@il06exm01.corp.mot.com> I haven't seen Embed, but if you want to use C in Perl (and don't want to use XS), you'll definitely want to get Inline (see http://search.cpan.org/search?module=Inline). - Rob -----Original Message----- From: Scott Walters [mailto:phaedrus@contactdesigns.com] Sent: Wednesday, August 01, 2001 9:46 AM To: phoenix-pm-list@happyfunball.pm.org Subject: Re: Phoenix.pm: Math Hey Tom, Well, looking at Math::BigInt/BigFloat, they do everything in Perl by unpacking into an array from a string... something in C or Perl that minipulated it directly in its binary format would be much faster... what problems were you having with perls built in operators? Overflow? Precision? Don't know of anything offhand, and I assume you've searched CPAN... If you wanted to use a C library, Doug just did a demo on [what was that?] Embed, which makes it really easy to stick some C right in middle of your Perl. -scott On Wed, 1 Aug 2001, Thomas Whitney wrote: > Hi All, > > I am doing a lot of decimal arithmetic. I ran into problems using perl's standard arithmetic. Right now I am using Math::BigFloat, but it seems slow. Can anybody recommend a better module > > Thanks > Tom > > From whitneyt at agcs.com Wed Aug 1 16:15:58 2001 From: whitneyt at agcs.com (Thomas Whitney) Date: Thu Aug 5 00:16:28 2004 Subject: Phoenix.pm: Math References: Message-ID: <3B68718E.DFDFA9C0@agcs.com> Thanks Scott, Here is the problem I was having last year. Just ran it again same problem. I am running on v5.6.0. I don't see anything wrong that I am doing. Script started on Thu Aug 17 15:57:29 2000 peoblej@holodeck[148]: cat bug.pl #!/usr/local/bin/perl -w use strict; my $result = 0.0; $result = 0.07 * 10000.0; printf "%40.35f\n", $result; peoblej@holodeck[149]: bug.pl 700.00000000000011368683772161602973938 peoblej@holodeck[150]: exit script done on Thu Aug 17 15:57:44 2000 Thanks Tom Scott Walters wrote: > Hey Tom, > > Well, looking at Math::BigInt/BigFloat, they do everything in Perl by > unpacking into an array from a string... something in C or Perl > that minipulated it directly in its binary format would be much faster... > what problems were you having with perls built in operators? Overflow? > Precision? Don't know of anything offhand, and I assume you've searched > CPAN... If you wanted to use a C library, Doug just did a demo on > [what was that?] Embed, which makes it really easy to stick some C > right in middle of your Perl. > > -scott > > On Wed, 1 Aug 2001, Thomas Whitney wrote: > > > Hi All, > > > > I am doing a lot of decimal arithmetic. I ran into problems using perl's standard arithmetic. Right now I am using Math::BigFloat, but it seems slow. Can anybody recommend a better module > > > > Thanks > > Tom > > > > From Rob.Svirskas at motorola.com Wed Aug 1 16:43:10 2001 From: Rob.Svirskas at motorola.com (Svirskas Rob-ERS007) Date: Thu Aug 5 00:16:28 2004 Subject: Phoenix.pm: Math Message-ID: <07077F6C2A38D511920800D0B7821B322A44BE@il06exm01.corp.mot.com> Tom; Your code is fine - the problem is just that numbers (floating point or otherwise) are stored in internal (binary) representation. The "extra digits" that you see tacked on the end are a consequence of how a floating point number is stored in binary format. The inconsistencies are compounded when you perform arithmetic operations. If you really need long floats, use Math::BigFloat. If it's precision you're worried about, check out Math::FixedPrecision. Both will be slow (compared to "straight math operations") due to overloading of arithmetic operators. Hope this helps. - Rob -----Original Message----- From: Thomas Whitney [mailto:whitneyt@agcs.com] Sent: Wednesday, August 01, 2001 2:16 PM To: phoenix-pm-list@happyfunball.pm.org Subject: Re: Phoenix.pm: Math Thanks Scott, Here is the problem I was having last year. Just ran it again same problem. I am running on v5.6.0. I don't see anything wrong that I am doing. Script started on Thu Aug 17 15:57:29 2000 peoblej@holodeck[148]: cat bug.pl #!/usr/local/bin/perl -w use strict; my $result = 0.0; $result = 0.07 * 10000.0; printf "%40.35f\n", $result; peoblej@holodeck[149]: bug.pl 700.00000000000011368683772161602973938 peoblej@holodeck[150]: exit script done on Thu Aug 17 15:57:44 2000 Thanks Tom Scott Walters wrote: > Hey Tom, > > Well, looking at Math::BigInt/BigFloat, they do everything in Perl by > unpacking into an array from a string... something in C or Perl > that minipulated it directly in its binary format would be much faster... > what problems were you having with perls built in operators? Overflow? > Precision? Don't know of anything offhand, and I assume you've searched > CPAN... If you wanted to use a C library, Doug just did a demo on > [what was that?] Embed, which makes it really easy to stick some C > right in middle of your Perl. > > -scott > > On Wed, 1 Aug 2001, Thomas Whitney wrote: > > > Hi All, > > > > I am doing a lot of decimal arithmetic. I ran into problems using perl's standard arithmetic. Right now I am using Math::BigFloat, but it seems slow. Can anybody recommend a better module > > > > Thanks > > Tom > > > > From edelweiss at qwest.net Wed Aug 1 17:16:16 2001 From: edelweiss at qwest.net (EdelSys Consulting) Date: Thu Aug 5 00:16:28 2004 Subject: Phoenix.pm: Math In-Reply-To: <07077F6C2A38D511920800D0B7821B322A44BE@il06exm01.corp.mot. com> Message-ID: <3.0.6.32.20010801151616.007c71e0@pop.phnx.qwest.net> Why not just use sprintf to round? What kind of precision we talking about here? "Throw me a frickin' bone here, Scott" -- Doctor Evil At 04:43 PM 8/1/01 -0500, you wrote: >Tom; > Your code is fine - the problem is just that numbers (floating point or otherwise) are stored in internal (binary) representation. The "extra digits" that you see tacked on the end are a consequence of how a floating point number is stored in binary format. The inconsistencies are compounded when you perform arithmetic operations. If you really need long floats, use Math::BigFloat. If it's precision you're worried about, check out Math::FixedPrecision. Both will be slow (compared to "straight math operations") due to overloading of arithmetic operators. Hope this helps. > - Rob > >-----Original Message----- >From: Thomas Whitney [mailto:whitneyt@agcs.com] >Sent: Wednesday, August 01, 2001 2:16 PM >To: phoenix-pm-list@happyfunball.pm.org >Subject: Re: Phoenix.pm: Math > > >Thanks Scott, > >Here is the problem I was having last year. Just ran it again same problem. I am running on v5.6.0. I don't see anything wrong that I am doing. > >Script started on Thu Aug 17 15:57:29 2000 >peoblej@holodeck[148]: cat bug.pl >#!/usr/local/bin/perl -w >use strict; > >my $result = 0.0; >$result = 0.07 * 10000.0; >printf "%40.35f\n", $result; >peoblej@holodeck[149]: bug.pl > 700.00000000000011368683772161602973938 >peoblej@holodeck[150]: exit >script done on Thu Aug 17 15:57:44 2000 > >Thanks >Tom > >Scott Walters wrote: > >> Hey Tom, >> >> Well, looking at Math::BigInt/BigFloat, they do everything in Perl by >> unpacking into an array from a string... something in C or Perl >> that minipulated it directly in its binary format would be much faster... >> what problems were you having with perls built in operators? Overflow? >> Precision? Don't know of anything offhand, and I assume you've searched >> CPAN... If you wanted to use a C library, Doug just did a demo on >> [what was that?] Embed, which makes it really easy to stick some C >> right in middle of your Perl. >> >> -scott >> >> On Wed, 1 Aug 2001, Thomas Whitney wrote: >> >> > Hi All, >> > >> > I am doing a lot of decimal arithmetic. I ran into problems using perl's standard arithmetic. Right now I am using Math::BigFloat, but it seems slow. Can anybody recommend a better module >> > >> > Thanks >> > Tom >> > >> > > > From whitneyt at agcs.com Wed Aug 1 22:05:27 2001 From: whitneyt at agcs.com (Thomas Whitney) Date: Thu Aug 5 00:16:28 2004 Subject: Phoenix.pm: Math References: <3.0.6.32.20010801151616.007c71e0@pop.phnx.qwest.net> Message-ID: <3B68C377.6AD512A5@agcs.com> I am parsing mathematical models where there are LONG expressions of various precessions, nothing too extreme. The error showed up when doing a ceiling function. I could us sprintf in my ceiling function to fix it and use perls math, but the error makes me a bit nervous, and considering the mathematical nature of the project, it probably isn't a good idea anyway. Using Math:BigFloat at least doubles the time. I saw a few modules on cpan that looked like they might work, but I have a have the sysadmin install them for me. Thanks Tom EdelSys Consulting wrote: > Why not just use sprintf to round? What kind of precision we > talking about here? > > "Throw me a frickin' bone here, Scott" > > -- Doctor Evil > > At 04:43 PM 8/1/01 -0500, you wrote: > >Tom; > > Your code is fine - the problem is just that numbers (floating point > or otherwise) are stored in internal (binary) representation. The "extra > digits" that you see tacked on the end are a consequence of how a floating > point number is stored in binary format. The inconsistencies are compounded > when you perform arithmetic operations. If you really need long floats, use > Math::BigFloat. If it's precision you're worried about, check out > Math::FixedPrecision. Both will be slow (compared to "straight math > operations") due to overloading of arithmetic operators. Hope this helps. > > - Rob > > > >-----Original Message----- > >From: Thomas Whitney [mailto:whitneyt@agcs.com] > >Sent: Wednesday, August 01, 2001 2:16 PM > >To: phoenix-pm-list@happyfunball.pm.org > >Subject: Re: Phoenix.pm: Math > > > > > >Thanks Scott, > > > >Here is the problem I was having last year. Just ran it again same > problem. I am running on v5.6.0. I don't see anything wrong that I am doing. > > > >Script started on Thu Aug 17 15:57:29 2000 > >peoblej@holodeck[148]: cat bug.pl > >#!/usr/local/bin/perl -w > >use strict; > > > >my $result = 0.0; > >$result = 0.07 * 10000.0; > >printf "%40.35f\n", $result; > >peoblej@holodeck[149]: bug.pl > > 700.00000000000011368683772161602973938 > >peoblej@holodeck[150]: exit > >script done on Thu Aug 17 15:57:44 2000 > > > >Thanks > >Tom > > > >Scott Walters wrote: > > > >> Hey Tom, > >> > >> Well, looking at Math::BigInt/BigFloat, they do everything in Perl by > >> unpacking into an array from a string... something in C or Perl > >> that minipulated it directly in its binary format would be much faster... > >> what problems were you having with perls built in operators? Overflow? > >> Precision? Don't know of anything offhand, and I assume you've searched > >> CPAN... If you wanted to use a C library, Doug just did a demo on > >> [what was that?] Embed, which makes it really easy to stick some C > >> right in middle of your Perl. > >> > >> -scott > >> > >> On Wed, 1 Aug 2001, Thomas Whitney wrote: > >> > >> > Hi All, > >> > > >> > I am doing a lot of decimal arithmetic. I ran into problems using > perl's standard arithmetic. Right now I am using Math::BigFloat, but it > seems slow. Can anybody recommend a better module > >> > > >> > Thanks > >> > Tom > >> > > >> > > > > > From phaedrus at contactdesigns.com Thu Aug 2 13:46:30 2001 From: phaedrus at contactdesigns.com (Scott Walters) Date: Thu Aug 5 00:16:28 2004 Subject: Phoenix.pm: Math In-Reply-To: <3B68C377.6AD512A5@agcs.com> Message-ID: Tom, Hmm. I'm having a thought there. Tony has the right idea - if you have enough precision with Perl internal math, but you're worried about acculating an error from repeated dec->bin->dec translation, why not overload the * and / and % operators, and add a truncation- rounding stage? This should be nearly as fast, as strings of binary data aren't being unpacked into an array at every operation, even though as Rob says overload has some overhead. My other thought is to see if your processor has a BCD (binary coded decimal) mode, and use Inline C with some inline assembler =) package StupidFloat; use Exporter; @EXPORT = qw(stupidfloat); sub stupidfloat { my $nombre = shift; my $value = 0.0; (my $callerpackage) = caller; *{$callerpackage.'::'.$nombre} = sub () : lvalue { $value = substr($value, 0, 14); }; } package Work; # use StupidFloat; # have to write a bloomin file for this to work StupidFloat::stupidfloat result; result() = (0.07 * 10000.0); printf "%40.35f\n", result(); Well, that wasn't quite what I expected. Turns out overloading operators is quite tricky, and only works when the variables the operators are operating on are objects. Makes a kinda OO sense, but then the variables don't work with normal operators, since they are then references... So I redid it with lambdas. I thought the sub : lvalue {} and the the sub () {} magic would work together (so that it would work in bareword form and then return an lvalue), but it didn't. Actually, on second thought, it's prolly just that it didnt appear with the correct name in the correct scope, since sub () { } is only a hint to the compiler..... ahh well. So, basicly, this works, but the "variable" you create, you have to tack ()'s onto the end or & in the front like a bloody function. In tyhe substr() call you can specify how many decimal degits of precesion you want to keep. It looks like its doing 14 but thats just a quick guess. -scott On Wed, 1 Aug 2001, Thomas Whitney wrote: > I am parsing mathematical models where there are LONG expressions of various > precessions, nothing too extreme. The error showed up when doing a ceiling > function. I could us sprintf in my ceiling function to fix it and use perls > math, but the error makes me a bit nervous, and considering the mathematical > nature of the project, it probably isn't a good idea anyway. Using Math:BigFloat > at least doubles the time. I saw a few modules on cpan that looked like they > might work, but I have a have the sysadmin install them for me. > > Thanks > Tom > > EdelSys Consulting wrote: > > > Why not just use sprintf to round? What kind of precision we > > talking about here? > > > > "Throw me a frickin' bone here, Scott" > > > > -- Doctor Evil > > > > At 04:43 PM 8/1/01 -0500, you wrote: > > >Tom; > > > Your code is fine - the problem is just that numbers (floating point > > or otherwise) are stored in internal (binary) representation. The "extra > > digits" that you see tacked on the end are a consequence of how a floating > > point number is stored in binary format. The inconsistencies are compounded > > when you perform arithmetic operations. If you really need long floats, use > > Math::BigFloat. If it's precision you're worried about, check out > > Math::FixedPrecision. Both will be slow (compared to "straight math > > operations") due to overloading of arithmetic operators. Hope this helps. > > > - Rob > > > > > >-----Original Message----- > > >From: Thomas Whitney [mailto:whitneyt@agcs.com] > > >Sent: Wednesday, August 01, 2001 2:16 PM > > >To: phoenix-pm-list@happyfunball.pm.org > > >Subject: Re: Phoenix.pm: Math > > > > > > > > >Thanks Scott, > > > > > >Here is the problem I was having last year. Just ran it again same > > problem. I am running on v5.6.0. I don't see anything wrong that I am doing. > > > > > >Script started on Thu Aug 17 15:57:29 2000 > > >peoblej@holodeck[148]: cat bug.pl > > >#!/usr/local/bin/perl -w > > >use strict; > > > > > >my $result = 0.0; > > >$result = 0.07 * 10000.0; > > >printf "%40.35f\n", $result; > > >peoblej@holodeck[149]: bug.pl > > > 700.00000000000011368683772161602973938 > > >peoblej@holodeck[150]: exit > > >script done on Thu Aug 17 15:57:44 2000 > > > > > >Thanks > > >Tom > > > > > >Scott Walters wrote: > > > > > >> Hey Tom, > > >> > > >> Well, looking at Math::BigInt/BigFloat, they do everything in Perl by > > >> unpacking into an array from a string... something in C or Perl > > >> that minipulated it directly in its binary format would be much faster... > > >> what problems were you having with perls built in operators? Overflow? > > >> Precision? Don't know of anything offhand, and I assume you've searched > > >> CPAN... If you wanted to use a C library, Doug just did a demo on > > >> [what was that?] Embed, which makes it really easy to stick some C > > >> right in middle of your Perl. > > >> > > >> -scott > > >> > > >> On Wed, 1 Aug 2001, Thomas Whitney wrote: > > >> > > >> > Hi All, > > >> > > > >> > I am doing a lot of decimal arithmetic. I ran into problems using > > perl's standard arithmetic. Right now I am using Math::BigFloat, but it > > seems slow. Can anybody recommend a better module > > >> > > > >> > Thanks > > >> > Tom > > >> > > > >> > > > > > > > > > From phaedrus at contactdesigns.com Thu Aug 2 13:52:15 2001 From: phaedrus at contactdesigns.com (Scott Walters) Date: Thu Aug 5 00:16:28 2004 Subject: Phoenix.pm: Math In-Reply-To: <3B68C377.6AD512A5@agcs.com> Message-ID: Oh, sorry. To further document... use StupidFloat; stupidfloat ; - generates a float "variable" named If you nest a bunch of expresssions, no rounding (truncation) will be down during it, only when data is retrieved from the "variable", so if you have a loop that is acculating binary noise, do: foreach my $i (0 .. 1_000_000) { var() = big(old_nasty_expression(that(includes(var()))); } making sure to retreive var every time. Hmm. Rather then putting () on the end of var, &var = 100.00 kinda looks more sane, more like $var. [Still jobless, if you haven't guessed] -scott From phaedrus at contactdesigns.com Thu Aug 2 13:55:40 2001 From: phaedrus at contactdesigns.com (Scott Walters) Date: Thu Aug 5 00:16:28 2004 Subject: Phoenix.pm: Math In-Reply-To: <3B68C377.6AD512A5@agcs.com> Message-ID: PS PS, the substr() thing is a real hack. Any math geek types out there who know a computationally FAST way to truncate floating point numbers? From phaedrus at contactdesigns.com Thu Aug 2 15:02:16 2001 From: phaedrus at contactdesigns.com (Scott Walters) Date: Thu Aug 5 00:16:28 2004 Subject: Phoenix.pm: Math In-Reply-To: Message-ID: Ok, folks, sorry for spam... last post for today. package StupidFloat; use Exporter; @EXPORT = qw(stupidfloat); sub stupidfloat { my $nombre = shift; my $value = 0.0; (my $callerpackage) = caller; *{$callerpackage.'::'.$nombre} = sub () : lvalue { $value = substr($value, 0, 14); }; eval("package $callerpackage;\nsub $nombre ();\n"); } package Work; # use StupidFloat; # have to write a bloomin file for this StupidFloat::stupidfloat result; result = (0.07 * 10000.0); printf "%40.35f\n", result; ... cleaner. Just evals up a prototype for the function/variable as it creates it so you can use it like a bareword. Which is how scalars should be, IMHO. Bet Larry Wall ever expected to see people assigning data to barewords... -s From macnaughtan at hotmail.com Thu Aug 2 18:42:38 2001 From: macnaughtan at hotmail.com (Heather Macnaughtan) Date: Thu Aug 5 00:16:28 2004 Subject: Phoenix.pm: Math Message-ID: Will somebody PLEASE give Scott a job??? :-) _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From edelweiss at qwest.net Thu Aug 2 23:51:00 2001 From: edelweiss at qwest.net (EdelSys Consulting) Date: Thu Aug 5 00:16:28 2004 Subject: Phoenix.pm: Math In-Reply-To: References: Message-ID: <3.0.6.32.20010802215100.007adc40@pop.phnx.qwest.net> That quote was from an Austin Powers movie. Scott Evil was Doctor Evil's son. Hope you didn't take it amiss, Scott. =) Tony At 04:02 PM 8/2/01 -0400, you wrote: > >Ok, folks, sorry for spam... last post for today. > >package StupidFloat; >use Exporter; >@EXPORT = qw(stupidfloat); > >sub stupidfloat { > my $nombre = shift; > my $value = 0.0; > (my $callerpackage) = caller; > *{$callerpackage.'::'.$nombre} = sub () : lvalue { > $value = substr($value, 0, 14); > }; > eval("package $callerpackage;\nsub $nombre ();\n"); >} > >package Work; ># use StupidFloat; # have to write a bloomin file for this >StupidFloat::stupidfloat result; >result = (0.07 * 10000.0); >printf "%40.35f\n", result; > > >... cleaner. Just evals up a prototype for the function/variable >as it creates it so you can use it like a bareword. Which is how >scalars should be, IMHO. Bet Larry Wall ever expected to see people >assigning data to barewords... > >-s > > > > From doug.miles at bpxinternet.com Mon Aug 13 11:11:17 2001 From: doug.miles at bpxinternet.com (Doug Miles) Date: Thu Aug 5 00:16:28 2004 Subject: Phoenix.pm: Meeting 08/16/2001 Message-ID: <3B77FC25.4020600@bpxinternet.com> We'll be having a Phoenix.pm meeting Thursday, August 16th at 7:00PM. It will be held at Bowne, which is located at 1500 N. Central Avenue, which is on the Southwest corner of Central and McDowell. The parking lot is gated, so just press the button on the intercom, and tell the receptionist that you are there for the Perl meeting. Park in the lot that is straight ahead from the entrance on the South side of McDowell. Park in any uncovered, non-reserved space. Proceed to the main lobby, which is on the Northeast side of the parking lot. Scott will be presenting his poll booth software. See you there! -- - Doug Don't anthropomorphize computers. They hate that. From Eden.Li at asu.edu Mon Aug 13 17:01:11 2001 From: Eden.Li at asu.edu (Eden.Li@asu.edu) Date: Thu Aug 5 00:16:28 2004 Subject: Phoenix.pm: Meeting 08/16/2001 In-Reply-To: <3B77FC25.4020600@bpxinternet.com> References: <3B77FC25.4020600@bpxinternet.com> Message-ID: <997740071.3b784e273ae82@webmail1.asu.edu> I'll be there :) Eden Quoting Doug Miles : > We'll be having a Phoenix.pm meeting Thursday, August 16th at 7:00PM. > It will be held at Bowne, which is located at 1500 N. Central Avenue, > which is on the Southwest corner of Central and McDowell. The parking > lot is gated, so just press the button on the intercom, and tell the > receptionist that you are there for the Perl meeting. Park in the lot > that is straight ahead from the entrance on the South side of > McDowell. > Park in any uncovered, non-reserved space. Proceed to the main lobby, > which is on the Northeast side of the parking lot. > > Scott will be presenting his poll booth software. See you there! > > -- > - Doug > > Don't anthropomorphize computers. They hate that. > > > > > From phaedrus at contactdesigns.com Mon Aug 13 17:27:29 2001 From: phaedrus at contactdesigns.com (Scott Walters) Date: Thu Aug 5 00:16:28 2004 Subject: Phoenix.pm: Meeting 08/16/2001 In-Reply-To: <3B77FC25.4020600@bpxinternet.com> Message-ID: Quick facts to hopefully intice people into attending PM: 1. Not easily stuffable... 2. ...because users must have accounts... 3. ...in the Multi User Dungeon that it reads login info from... 4. ...where it uses crypt() to velidate passwords. 5. Allocates "one" vote per person... 6. ...but allows voting multiple times and for multiple things... 7. ...and subdivides your vote accrost each thing you vote for It's a quickie script, but hopefully it will spur Perl-related conversation *cough* -scott On Mon, 13 Aug 2001, Doug Miles wrote: > We'll be having a Phoenix.pm meeting Thursday, August 16th at 7:00PM. > It will be held at Bowne, which is located at 1500 N. Central Avenue, > which is on the Southwest corner of Central and McDowell. The parking > lot is gated, so just press the button on the intercom, and tell the > receptionist that you are there for the Perl meeting. Park in the lot > that is straight ahead from the entrance on the South side of McDowell. > Park in any uncovered, non-reserved space. Proceed to the main lobby, > which is on the Northeast side of the parking lot. > > Scott will be presenting his poll booth software. See you there! > > -- > - Doug > > Don't anthropomorphize computers. They hate that. > > > > > From Bryan.Lane at VITALPS.COM Tue Aug 14 18:57:07 2001 From: Bryan.Lane at VITALPS.COM (Bryan Lane) Date: Thu Aug 5 00:16:28 2004 Subject: Phoenix.pm: Meeting 08/16/2001 Message-ID: <219B26AF200FD411A11200805FE6EF2503B3F4EE@tef00021.vitalps.com> I should be there! > -----Original Message----- > From: doug.miles@bpxinternet.com [SMTP:doug.miles@bpxinternet.com] > Sent: Monday, August 13, 2001 9:11 AM > To: Phoenix.pm > Cc: Rose Keys > Subject: Phoenix.pm: Meeting 08/16/2001 > > We'll be having a Phoenix.pm meeting Thursday, August 16th at 7:00PM. > It will be held at Bowne, which is located at 1500 N. Central Avenue, > which is on the Southwest corner of Central and McDowell. The parking > lot is gated, so just press the button on the intercom, and tell the > receptionist that you are there for the Perl meeting. Park in the lot > that is straight ahead from the entrance on the South side of McDowell. > Park in any uncovered, non-reserved space. Proceed to the main lobby, > which is on the Northeast side of the parking lot. > > Scott will be presenting his poll booth software. See you there! > > -- > - Doug > > Don't anthropomorphize computers. They hate that. > > > From macnaughtan at hotmail.com Wed Aug 15 11:00:14 2001 From: macnaughtan at hotmail.com (Heather Macnaughtan) Date: Thu Aug 5 00:16:28 2004 Subject: Phoenix.pm: Meeting 08/16/2001 Message-ID: I'll try to make it by 7; I have to take my dog to the vet after work first. :-) _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From doug.miles at bpxinternet.com Thu Aug 16 15:32:07 2001 From: doug.miles at bpxinternet.com (Doug Miles) Date: Thu Aug 5 00:16:28 2004 Subject: Reminer: Phoenix.pm: Meeting 08/16/2001 Message-ID: <3B7C2DC7.7070604@bpxinternet.com> Please RSVP if you haven't already. We'll be having a Phoenix.pm meeting Thursday, August 16th at 7:00PM. It will be held at Bowne, which is located at 1500 N. Central Avenue, which is on the Southwest corner of Central and McDowell. The parking lot is gated, so just press the button on the intercom, and tell the receptionist that you are there for the Perl meeting. Park in the lot that is straight ahead from the entrance on the South side of McDowell. Park in any uncovered, non-reserved space. Proceed to the main lobby, which is on the Northeast side of the parking lot. Scott will be presenting his poll booth software. See you there! -- - Doug Don't anthropomorphize computers. They hate that. From djmilesfamily at earthlink.net Thu Aug 30 20:43:10 2001 From: djmilesfamily at earthlink.net (Doug and Julie Miles) Date: Thu Aug 5 00:16:28 2004 Subject: Phoenix.pm: Fwd: PERL, PHP and Linux Jobs Message-ID: <5.0.2.1.0.20010830183908.02611c10@mail.earthlink.net> I wouldn't normally forward spam, but I know some of you are looking for jobs. Hopefully this is useful... >Dear Sir/Madam, > >We would like to invite you to visit our new job portal at >http://www.openoid.com, >dedicated to "Open Source Community" in the spirit of "Open Source". > >You are welcome to search/post unlimited of IT related jobs in Openoid.com >for free. > >Visit us now at http://www.openoid.com > >Thank you for your time. > >Best regards, > >Stanley Quek, >Site Manager, >Openoid.com >Note: This is not a mailing list.