Re: Benchmark Stuff
On Tuesday 24 August 2004 20:29, Joshua Gatcomb wrote: > I don't know what kind of layout/data would be useful > to people so let me know if you want something else. > I will update every Tuesday morning. And here's a script that use your sqlite database to generate rrd file and graph results. You will need RRDs.pm installed (Perl binding of rrdtool) - download at www.rrdtool.org or use your favorite packaging tool. The script is quite dirty: - it's not really portable for non-unix platforms (although it might not be difficult to change) - it's not really portable for perl < 5.8.0 (although it might not be difficult to change) - I'm deleting, recreating and repopulating the rrd files each time, but this way I'm free regarding Joshua's way of parsing - I'm generating fixed pngs with the results of the last 8 weeks - I'm just generating graphs, not the html that wrap them Anyway, it works. Now, I'm a bit concerned about the frequency: is once a week is enough? Joshua, I don't know if that's possible to run benchmarks once a day? If you can / think it's ok, then I'll update the script to use new values for rrd creation. Additionaly, maybe later it would be better to just drop the sqlite database and ue rrd directly? Regards, Jerome -- [EMAIL PROTECTED] rrdit.pl Description: Perl program
Re: Order of types (revised)
On Wed, 2004-08-25 at 13:03 -0400, Dan Sugalski wrote: > Okay, as has been suggested, the type order for numbers should go: > > int->bignum->float > > owing to the fact that floats are lossy and nasty. I'm not entirely > sure I agree, given that floats are supported in hardware and faster > (I've gotten a suggestion that we only do float and bignum for PMCs, > since float ops are nearly as fast as int ops, and there are more > bits, but the quiet loss of precision bothers me enough that I'm not > sure I'm up for that) but it's a sensible argument. Can't this be something config-able? On my machine, perl -e '$c++ while ((2**$c)!=(2**$c + 1)); print ($c-1)' prints 52, which seems a lot better than the ~32 available for most people's ints. I can't imagine immediately any reason why the promotion to a bignum for >52 bit ints would be conceptually different than a promotion to a double for >32 bit ints. Did I accidentally delete some important bits of the conversation? Peter
Re: This fortnight's summary
These stuff-its should, of course, be stuffed into RT as TODO tickets. Not that I'm a zealot or anything. John Macdonald wrote: On Wed, Aug 25, 2004 at 08:19:06PM +0100, The Perl 6 Summarizer wrote: A small task for the interested Dan posted another of his small tasks for the interested (maybe we should start calling them STFTIs?). This time he's after source tests to test the embedding interface and some fixing of the auto-prefix scheme. Hmm... I suppose that this acronym would be pronounced "stuff-it".
RE: This fortnight's summary
None of the links for the perl6-language threads work. Joe Gottman
parrotbench.pl - massive update
I hadn't really expected Leo to check in my modifications to parrotbench.pl. I took the time today to give it a proper overhaul/re-write, so please try it out. If after a few days no one grumbles, I will ask for it to be checked in. Enhancements: 1. Should be platform independent now 2. Much greater control using ini configuration 3. Output is "pretty" 4. Lots of bugs squashed (probably more introduced) 5. POD updated 6. Multiple regexes allowed for benchmarks to be run 7. Multiple regexes allowed for benchmarks to be skipped 8. Probably some stuff I am forgetting Joshua Gatcomb a.k.a. Limbic~Region ___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush parrotbench.gat Description: parrotbench.gat
Re: This fortnight's summary
On Wed, Aug 25, 2004 at 08:19:06PM +0100, The Perl 6 Summarizer wrote: > A small task for the interested > Dan posted another of his small tasks for the interested (maybe we > should start calling them STFTIs?). This time he's after source tests to > test the embedding interface and some fixing of the auto-prefix scheme. Hmm... I suppose that this acronym would be pronounced "stuff-it". --
Re: Order of types (revised)
On Wed, Aug 25, 2004 at 01:03:07PM -0400, Dan Sugalski wrote: > Okay, as has been suggested, the type order for numbers should go: > >int->bignum->float > > owing to the fact that floats are lossy and nasty. I'm not entirely > sure I agree, given that floats are supported in hardware and faster > To recap the rest of the behaviors, basic math operations (addition, > subtraction, multiplication, division, and modulus) produce a result > that's of a type no tighter than the loosest type in the operation > (so int+bignum gets a bignum, but int+int will be an int if the > result fits, or a bignum if it doesn't), and error operations > (division by zero, overflow, or precision loss) throw an exception. I'm not sure that I agree, because for int,int operations (except division with a non-integer result) you can know if the result will fit in a float without loss. Nicholas Clark
Re: Breathing new life into mod_parrot
> I caught up with Kevin on irc (#parrot on irc.perl.org, for anyone > who cares :) and he lacks the tuits to do anything with it. now that the summer is winding down, i've got plenty of those. so i guess that's me volunteering. -jeff
Re: Breathing new life into mod_parrot
At 4:11 PM -0400 8/25/04, Jeff Horwitz wrote: kevin falcone gave a short mod_parrot talk at YAPC this year. does he want to lay some claim to it? i'd be willing to pick it up if nobody else speaks up -- a decision i'm sure to regret... ;-) I caught up with Kevin on irc (#parrot on irc.perl.org, for anyone who cares :) and he lacks the tuits to do anything with it. on a related note, last year i wrote extproc_parrot, which lets you call parrot bytecode as an oracle stored procedure. this was a proof of concept to show that to show that extproc_perl (stored procedures in perl) would be able to support perl 6 when it became available. it worked, but the embedding interface was too immature to do much else than a simple "Hello world" example. based on what you're saying here, i plan on picking this up again. i imagine the work will be quite similar to mod_parrot. Yep, I expect there will be a massive amount of overlap. This could be interesting... :) On Wed, 25 Aug 2004, Dan Sugalski wrote: Okay, here's the scoop. Ages ago, Clever People whipped up mod_parrot, an apache module that embedded parrot. This was really cool. Alas, Parrot wasn't up to snuff at the time, and the project languished. This wasn't cool, but neither was it unsurprising. I think we're at the point where mod_parrot is feasible, so I'd like to find someone willing to pick up the project and get it going again. This should let us exercise the embedding interface with something a bit less stressful than ponie, and we'll get a chance to work out the API for setting up IO streams, which'll be nice. This is a bit of a big'un, but when it works it'll be the basis for the parrot version of mod_[perl|python|ruby|tcl|Intercal|Forth] so if you've got a bit of time, well... fame and potential madness (or > madness and potential fame, I could see it going either way) await. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: NCI and callback functions
On Tue, Aug 24, 2004 at 09:44:56AM +0200, Leopold Toetsch wrote:
> Whatever you'll try the current scheme is not compatible with this GTK
> callback. Parrot needs a PMC as user_data. GTK awaits a GObject.
> Yes. But draining the event queue still needs a running Parrot runloop.
This made me remember that Ive tried sometime ago another of those gtk
callback installer function that is g_signal_connect_data (wich is what
the #defined g_signal_connect uses actually. That didn't broke, or even
freeze the app, or else.. but it was "say" actually working.. o well..
Mainly Ive traced it to be sure and indeed, parrot is properly called each
time the button pressed. Just that, as you say, parrot piles it up in its
event queue.. and never takes it, since its busy "doing gtk_main".
Well at least I know for sure how the whole callback scheme works now in
parrot and can go try this:
> >Otherwise, already thaught of actually unrolling the gtk_main function
> >and have it handled/implemented within parrot directly (mainly gtk_main
> >simply loops and waits on the gtk event queue).
>
> That's the way to go.
! :)
Thanks,
Stephane
# -- Gtk Button Example.
.sub _gtkcallback
print "Hello\n"
.end
.sub _main @MAIN
.include "glib.pasm"
.include "gtk.pasm"
.local pmc window
.local pmc button
.local pmc callback
.local pmc userdata
.local NCI init
init = global "Gtk::gtk_init"
init(0)
# -- create the window
.local NCI w_new
w_new = global "Gtk::gtk_window_new"
window = w_new(0)
# -- create the button
.local NCI b_new
b_new = global "Gtk::gtk_button_new_with_label"
button = b_new("Parrot")
# -- install callback?
.local pmc cb_sub
cb_sub = global "_gtkcallback"
userdata = new Integer
userdata = 42
callback = new_callback cb_sub, userdata, "pU"
# -- function sig is "'lptppi', then we have:
#P5 is the button
#P6 the callback
#P7 data we may to pass through.
#S5 "clicked"
#I5 is 0
# -- Uncomment this section to actually install the callback
# -- (this segfaulst on my system)
.local NCI sig_conn
sig_conn = global "Glib::g_signal_connect_data"
sig_conn(button, "clicked", callback, userdata, 0, 0)
# -- Set the container.
.local NCI cont_add
cont_add = global "Gtk::gtk_container_add"
cont_add(window, button)
# -- show button
.local NCI w_show
w_show = global "Gtk::gtk_widget_show"
w_show(button)
# -- show window
w_show(window)
.local NCI g_main
g_main = global "Gtk::gtk_main"
g_main()
end
.end
saveall
loadlib P1, 'libgtk-x11-2.0'
dlfunc P2, P1, 'gtk_init', 'vii'
store_global 'Gtk::gtk_init', P2
dlfunc P2, P1, 'gtk_main', 'vv'
store_global 'Gtk::gtk_main', P2
dlfunc P2, P1, 'gtk_widget_show', 'vp'
store_global 'Gtk::gtk_widget_show', P2
dlfunc P2, P1, 'gtk_container_add', 'vpp'
store_global 'Gtk::gtk_container_add', P2
dlfunc P2, P1, 'gtk_button_new_with_label', 'pt'
store_global 'Gtk::gtk_button_new_with_label', P2
dlfunc P2, P1, 'gtk_window_new', 'pi'
store_global 'Gtk::gtk_window_new', P2
restoreall
saveall
loadlib P1, 'libgobject-2.0'
dlfunc P2, P1, 'g_signal_connect_data', 'lptpPii'
store_global 'Glib::g_signal_connect_data', P2
restoreall
Re: Breathing new life into mod_parrot
kevin falcone gave a short mod_parrot talk at YAPC this year. does he want to lay some claim to it? i'd be willing to pick it up if nobody else speaks up -- a decision i'm sure to regret... ;-) on a related note, last year i wrote extproc_parrot, which lets you call parrot bytecode as an oracle stored procedure. this was a proof of concept to show that to show that extproc_perl (stored procedures in perl) would be able to support perl 6 when it became available. it worked, but the embedding interface was too immature to do much else than a simple "Hello world" example. based on what you're saying here, i plan on picking this up again. i imagine the work will be quite similar to mod_parrot. -jeff On Wed, 25 Aug 2004, Dan Sugalski wrote: > Okay, here's the scoop. Ages ago, Clever People whipped up > mod_parrot, an apache module that embedded parrot. This was really > cool. > > Alas, Parrot wasn't up to snuff at the time, and the project > languished. This wasn't cool, but neither was it unsurprising. > > I think we're at the point where mod_parrot is feasible, so I'd like > to find someone willing to pick up the project and get it going > again. This should let us exercise the embedding interface with > something a bit less stressful than ponie, and we'll get a chance to > work out the API for setting up IO streams, which'll be nice. > > This is a bit of a big'un, but when it works it'll be the basis for > the parrot version of mod_[perl|python|ruby|tcl|Intercal|Forth] so if > you've got a bit of time, well... fame and potential madness (or > madness and potential fame, I could see it going either way) await. > -- > Dan > > --it's like this--- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even >teddy bears get drunk >
Breathing new life into mod_parrot
Okay, here's the scoop. Ages ago, Clever People whipped up mod_parrot, an apache module that embedded parrot. This was really cool. Alas, Parrot wasn't up to snuff at the time, and the project languished. This wasn't cool, but neither was it unsurprising. I think we're at the point where mod_parrot is feasible, so I'd like to find someone willing to pick up the project and get it going again. This should let us exercise the embedding interface with something a bit less stressful than ponie, and we'll get a chance to work out the API for setting up IO streams, which'll be nice. This is a bit of a big'un, but when it works it'll be the basis for the parrot version of mod_[perl|python|ruby|tcl|Intercal|Forth] so if you've got a bit of time, well... fame and potential madness (or madness and potential fame, I could see it going either way) await. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
This fortnight's summary
The Perl 6 Summary for the fortnight ending 2004-08-20 Harrumph. Note to self; never miss a week when you could actually have written the summary. I lulled myself into a false sense of security with the quiet week for the last summary. The last two weeks have been rather more busy and I've been away at EuroFoo over the weekend. So, this fortnight's summary might be a bit sketchy. We're back with starting with perl6-internals this time as it continues to comfortably out traffic perl6-language (message count was running about 3:1 in favour of p6i). Register allocation Work continued apace on adding a bullet proof failsafe register spilling algorithm so that Dan's work project could be made to at least compile. There was much discussion of what was actually causing the problem and several attempts to fix it. Work is ongoing. Melvin Smith coined a new acronym: DSWEPIC, which stands for Dan Stop Writing Evil Pathological Intermediate Code though, as chromatic pointed out, it's actually Dan's compiler that's generating Evil Pathological code and Dan claimed that that's because he's writing a compiler for an Evil Pathological language. http://xrl.us/cub5 Parrot cvs mirrored with svk Chia-liang Kao announced that he (I'm guessing, I'm not very good at divining the gender of none western names. Sadly 'he' is usually a safe bet in this field though) was mirroring the Parrot CVS repository in a Subversion repository for those who didn't like CVS. There was a certain amount of chuntering but most people seemed pleased by this. http://xrl.us/cub7 The Pie-thon post-mortem Dan posted his notes on the aftermath of the pie-thon push. Next time we do this, we'll start earlier. http://xrl.us/cub8 An alternate call scheme Dan ruled on Leo's alternate call scheme proposal, but wasn't entirely comfortable with it. However, he sketched out another idea inspired by it. Leo didn't sound convinced. http://xrl.us/cub9 Source mangling slides Dan posted a link to an abortive talk on some of the cunning tricks we do with source mangling in Parrot. http://xrl.us/cuca http://xrl.us/cucb Making NCI work with a nasty library Hildo Biersma is trying to write parrot support for IBM's MQ library. He had a couple of questions about the best way to go about it. Leo and chromatic had some suggestions. http://xrl.us/cucc Functions for embedders to override Noting that Ponie was already have problems, Dan outlined those functions that embedding environments may need to override to get things working. He asked for help and comments in getting a system in place to allow overriding functions to be registered in order to give embedders control over parrot's interface to the real world. This is something which needs doing sooner rather than later so as to avoid storing up pain. This triggered a fairly wide ranging discussion, but progress is being made. http://xrl.us/cucd What Unicode means to us Mmm... Unicode. Dan outlined what need to deal with to do Unicode sufficiently well. Discussion ensued. http://xrl.us/cuce Fix generation of src/nci.c to be more efficient I don't normally point out patches, but Dan's patch to improve the generation of src/nci.c spawned a longish thread with commentary from Nicholas Clark and chromatic. http://xrl.us/cucf A small task for the interested Dan posted another of his small tasks for the interested (maybe we should start calling them STFTIs?). This time he's after source tests to test the embedding interface and some fixing of the auto-prefix scheme. http://xrl.us/cucg The encoding API Dan detailed the encoding API, the layer that mediates between Parrot, which sees strings as a sequence of codepoints and the underlying buffer full of bytes. Gopal V and Michael Stone had questions and suggestions. http://xrl.us/cuch COBOL on Parrot? Remember Dan pointed everyone at a GPL'd COBOL compiler and suggested that a Parrot backend would be cool? David Essex (if that's the British singer from the 70s then I'll be boggling like a good 'un) pointed everyone at a couple of others. He and Uri Guttman discussed runtime libraries. http://xrl.us/cuci The Perl 6 compiler pumpking Patrick Michaud, Perl 6 compiler pumpking, outlined his plan for getting us to a working Perl 6 compiler. http://xrl.us/cucj PMC semantics Leo kicked off what looks like being a long running thread when he opened discussion of the semantics of the various integerish PMCs in Parrot. Larry and Dan both pitched in with discussion. http://xrl.us/cuck Charset API Dan posted part two of the charset API, which confused me slightly by arriving on my computer before Part 1. http://xrl.us/
Re: Test::Harness with modules that output to STDOUT
-BEGIN PGP SIGNED MESSAGE- Helo, On Wednesday 25 August 2004 02:47, Ovid wrote: > --- Peter Kay <[EMAIL PROTECTED]> wrote: > > Ok, what's the elegent way to ignore/dispose of the output the tested > > module produces? > > What I do whenever this happens is to move the printing code to a > subroutine or method and override that to capture the output. So if I > have something like this: [snip a lot] I use the same technique quite frequently (but didn't know about Sub::Override :o). Best wishes, Tels - -- Signed on Wed Aug 25 18:56:54 2004 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. "I can imagine what you're thinking though: this girl keeps her brains in her backside! But actually only the more primitive parts of my brain are in my butt. The more interesting parts are kept in a PC - my spinal cord is actually an RS232 lead!" - Lucy, the OrangUtan Robot Girl http://tinyurl.com/3fv6z -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl. iQEVAwUBQSzE13cLPEOTuEwVAQHAVwf+P+IkU60930MD+zOGyx8GjoXDP0aLmk/+ aKnVtVU+dTxh/wF9iuUjd5jG/f/M6R/1jeMAOt0gpiOomyWTAQBlL8BCF23jDhyn h39p4GmWxuBiznZhJr1FkWeGq9sWtqosNF2AUVKzixQmQqQkeUmvCrWWCL/FYV6X H13SJ+P2EPWV9MyPEuL/lx6Pw3IrAgeHLUhqLfxMDqxEqD7IdEL46EQnYPk/+3Qs lMEH8B7pgW1b9QOOYdR8f9bQAedmM+arMc2TwZr5vU/TbsTHYc7JCB5tMkFLRNKh p+4usn+36mtwFHSgW1Pe2RpiK4EcZ1//tdUxKxuvcERnCYq5LBfrJw== =ePhp -END PGP SIGNATURE-
Order of types (revised)
Okay, as has been suggested, the type order for numbers should go: int->bignum->float owing to the fact that floats are lossy and nasty. I'm not entirely sure I agree, given that floats are supported in hardware and faster (I've gotten a suggestion that we only do float and bignum for PMCs, since float ops are nearly as fast as int ops, and there are more bits, but the quiet loss of precision bothers me enough that I'm not sure I'm up for that) but it's a sensible argument. To recap the rest of the behaviors, basic math operations (addition, subtraction, multiplication, division, and modulus) produce a result that's of a type no tighter than the loosest type in the operation (so int+bignum gets a bignum, but int+int will be an int if the result fits, or a bignum if it doesn't), and error operations (division by zero, overflow, or precision loss) throw an exception. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Tight typing by default?
At 6:04 PM +0200 8/25/04, Jerome Quelin wrote: On Wednesday 25 August 2004 14:38, Dan Sugalski wrote: For our purposes I think the typing should go: platform int->float->bignum No int64? Nope, though you can build parrot with 64-bit native ints if you want. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Tight typing by default?
On Wednesday 25 August 2004 14:38, Dan Sugalski wrote: > For our purposes I think the typing should go: > platform int->float->bignum No int64? Jerome -- [EMAIL PROTECTED]
RE: Numeric semantics for base pmcs
BigNum is an arbitrary precision decimal number (Think BCD -- Binary Coded Decimal ala the Unix utility BC) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 25, 2004 9:12 AM To: [EMAIL PROTECTED] Subject: RE: Numeric semantics for base pmcs On Wed, 25 Aug 2004 08:40:32 -0400, "Gay, Jerry" <[EMAIL PROTECTED]> said: > Leopold Toetsch <[EMAIL PROTECTED]> wrote: > > BigNums grow on demand. It depends on value and precision. > > > > can BigNum then start at sizeof(int)? overflow would auto-grow the BigNum > to > the appropriate size, and most integer math operations will keep space > usage > as low as possible. > > in fact, then int is just a degenerate case of BigNum, one that doesn't > grow > and throws an exception instead. or, maybe that's the case already, i > should > probably read the docs. > > ~jerry > What is the most reasonable paradigm for scientific/high precision applications? It seems to me that this type of thing has been hashed out before, and it should be designed in a way that makes it attractive/sellable for scientists, engineers, etc. One handicap that Perl has (by reputation only) in the sciences is that it is not good for precision math. I know this is not true, and you all know this is not true, but the community(ies) at large do not know - they are stuck in the land of Fortran, and from my experience people are by-passing Perl for things like Python when they do venture out. Just out of curiosity, is BigNum like a "double" (16 bit) or is it just limited by the precision of the machine, i.e. 32 or 64 bit? Thanks, Brett Perl6 ToDo: http://www.parrotcode.org/todo The information contained in this e-mail message is privileged and/or confidential and is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by telephone (330-668-5000), and destroy the original message. Thank you.
Re: Tight typing by default?
Dan Sugalski <[EMAIL PROTECTED]> writes: > It seems pretty clear that the general opinion is that operations > should produce the tightest reasonable type for an operation--integer > multiplication should produce an integer unless it can't, for example. > > For our purposes I think the typing should go: > >platform int->float->bignum > > with an operation producing a type no tighter than the loosest type > in the operation. (so int/float gives a float, float-bignum gives a > bignum) > > This seem reasonable? No. int->bignum->float In other words, floats only happen if you specifically introduce them (or take a square root or something).
RE: Tight typing by default?
It would also seem reasonable that *IF* the promotion checking requires any significant amount of resources that there be a non-promoting version/mode of the ops for calculations that are known a priori to not overflow (e.g. i = 0; i = i + 1; <=== Should be able to be designated *somehow* to not check for overflow) -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 25, 2004 8:39 AM To: [EMAIL PROTECTED] Subject: Tight typing by default? It seems pretty clear that the general opinion is that operations should produce the tightest reasonable type for an operation--integer multiplication should produce an integer unless it can't, for example. For our purposes I think the typing should go: platform int->float->bignum with an operation producing a type no tighter than the loosest type in the operation. (so int/float gives a float, float-bignum gives a bignum) This seem reasonable? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk The information contained in this e-mail message is privileged and/or confidential and is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by telephone (330-668-5000), and destroy the original message. Thank you.
RE: Numeric semantics for base pmcs
At 8:11 AM -0500 8/25/04, [EMAIL PROTECTED] wrote: On Wed, 25 Aug 2004 08:40:32 -0400, "Gay, Jerry" <[EMAIL PROTECTED]> said: Leopold Toetsch <[EMAIL PROTECTED]> wrote: > BigNums grow on demand. It depends on value and precision. > can BigNum then start at sizeof(int)? overflow would auto-grow the BigNum to the appropriate size, and most integer math operations will keep space usage as low as possible. in fact, then int is just a degenerate case of BigNum, one that doesn't grow and throws an exception instead. or, maybe that's the case already, i should probably read the docs. ~jerry What is the most reasonable paradigm for scientific/high precision applications? It seems to me that this type of thing has been hashed out before, and it should be designed in a way that makes it attractive/sellable for scientists, engineers, etc. One handicap that Perl has (by reputation only) in the sciences is that it is not good for precision math. I know this is not true, and you all know this is not true, but the community(ies) at large do not know - they are stuck in the land of Fortran, and from my experience people are by-passing Perl for things like Python when they do venture out. We're only talking about the behavior for the base parrot types. Individual languages can, and will, have different behaviors for their own base types. This can be an issue in two spots: 1) If we want parrot's basic types to be sufficiently rich that people don't bother with other types (which is certainly a reasonable thing to think) 2) The default functions ought to be sensible enough so languages don't have to fill in too many slots of the MMD table. I think that if we up-convert where necessary and have Undef do the right thing on assignment (that was detailed earlier, and I think it's specified sufficiently and sufficiently correctly :) we'll be covered. Just out of curiosity, is BigNum like a "double" (16 bit) or is it just limited by the precision of the machine, i.e. 32 or 64 bit? BigNum's an indefinite-precision floating-point number. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Numeric semantics for base pmcs
On Wed, 25 Aug 2004 08:40:32 -0400, "Gay, Jerry" <[EMAIL PROTECTED]> said: > Leopold Toetsch <[EMAIL PROTECTED]> wrote: > > BigNums grow on demand. It depends on value and precision. > > > > can BigNum then start at sizeof(int)? overflow would auto-grow the BigNum > to > the appropriate size, and most integer math operations will keep space > usage > as low as possible. > > in fact, then int is just a degenerate case of BigNum, one that doesn't > grow > and throws an exception instead. or, maybe that's the case already, i > should > probably read the docs. > > ~jerry > What is the most reasonable paradigm for scientific/high precision applications? It seems to me that this type of thing has been hashed out before, and it should be designed in a way that makes it attractive/sellable for scientists, engineers, etc. One handicap that Perl has (by reputation only) in the sciences is that it is not good for precision math. I know this is not true, and you all know this is not true, but the community(ies) at large do not know - they are stuck in the land of Fortran, and from my experience people are by-passing Perl for things like Python when they do venture out. Just out of curiosity, is BigNum like a "double" (16 bit) or is it just limited by the precision of the machine, i.e. 32 or 64 bit? Thanks, Brett Perl6 ToDo: http://www.parrotcode.org/todo
RE: Tight typing by default?
At 8:47 AM -0400 8/25/04, Butler, Gerald wrote: It would also seem reasonable that *IF* the promotion checking requires any significant amount of resources that there be a non-promoting version/mode of the ops for calculations that are known a priori to not overflow (e.g. i = 0; i = i + 1; <=== Should be able to be designated *somehow* to not check for overflow) Remember that this is just for binary PMC operations, so there's a limit to the amount of information that's available here. Skipping overflow checking means either some sort of flag or an alternate mmd slot (with a corresponding op). I think for right now we won't, though we can revisit that later if it becomes necessary. -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 25, 2004 8:39 AM To: [EMAIL PROTECTED] Subject: Tight typing by default? It seems pretty clear that the general opinion is that operations should produce the tightest reasonable type for an operation--integer multiplication should produce an integer unless it can't, for example. For our purposes I think the typing should go: platform int->float->bignum with an operation producing a type no tighter than the loosest type in the operation. (so int/float gives a float, float-bignum gives a bignum) This seem reasonable? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Numeric semantics for base pmcs
Leopold Toetsch <[EMAIL PROTECTED]> wrote: > BigNums grow on demand. It depends on value and precision. > can BigNum then start at sizeof(int)? overflow would auto-grow the BigNum to the appropriate size, and most integer math operations will keep space usage as low as possible. in fact, then int is just a degenerate case of BigNum, one that doesn't grow and throws an exception instead. or, maybe that's the case already, i should probably read the docs. ~jerry ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance.
Tight typing by default?
It seems pretty clear that the general opinion is that operations should produce the tightest reasonable type for an operation--integer multiplication should produce an integer unless it can't, for example. For our purposes I think the typing should go: platform int->float->bignum with an operation producing a type no tighter than the loosest type in the operation. (so int/float gives a float, float-bignum gives a bignum) This seem reasonable? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Numeric semantics for base pmcs
Leopold Toetsch <[EMAIL PROTECTED]> writes: > Dan Sugalski <[EMAIL PROTECTED]> wrote: >> At 8:45 PM +0200 8/24/04, Leopold Toetsch wrote: >>>Dan Sugalski <[EMAIL PROTECTED]> wrote: > Nope -- we don't have bigints. :) >>> >>>Pardon, sir? > >> We've got the big number code, but I don't see much reason to >> distinguish between integers and non-integers at this level -- the >> only difference is exponent twiddling. > > Ah, ok. BigInt as a degenerated BigNum. I still prefer the notion that > adding or multiplying to integers give a BigInt on overflow. > > While at num vs int: do we automatically downgrade to int again? > > 6.0/2.0 = 3.0 or 3 ? No. Once a real, always a real. I see no harm in collapsing appropriate rationals to ints mind...
