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 muc
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 ope
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 i
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; <=== S
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
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
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
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 sh
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
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]
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.
--
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,
s
-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
>
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 a
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_p
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
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 rem
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,
> 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
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 fas
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 s
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 g
None of the links for the perl6-language threads work.
Joe Gottman
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
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
>
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.
Y
26 matches
Mail list logo
