At 08:58 AM 3/30/2001 -0500, Andy Dougherty wrote:
>On Fri, 30 Mar 2001, Bart Lateur wrote:
>
> > On Thu, 29 Mar 2001 19:24:21 +0200 (CEST), Tels wrote:
> >
> > >And then, if we have BigFloat, we need a way to specify rounding and
> > >precision. Otherwise 1/3 eats up all memory or provides limits
Bart Lateur wrote:
>
> Er... may I suggest ratio's as a data format? It won't work for sqrt(2)
> or PI, but it can easily store 1/3 as two (long) integers. You can
> postpone doing integer divisions until you need a result, at which time
^to stri
-BEGIN PGP SIGNED MESSAGE-
Moin,
>>And then, if we have BigFloat, we need a way to specify rounding and
>>precision. Otherwise 1/3 eats up all memory or provides limits ;o)
>
>Er... may I suggest ratio's as a data format? It won't work for sqrt(2)
>or PI, but it can easily store 1/3 as t
On Fri, 30 Mar 2001, Bart Lateur wrote:
> On Thu, 29 Mar 2001 19:24:21 +0200 (CEST), Tels wrote:
>
> >And then, if we have BigFloat, we need a way to specify rounding and
> >precision. Otherwise 1/3 eats up all memory or provides limits ;o)
> Er... may I suggest ratio's as a data format? It wo
On Thu, 29 Mar 2001 19:24:21 +0200 (CEST), Tels wrote:
>And then, if we have BigFloat, we need a way to specify rounding and
>precision. Otherwise 1/3 eats up all memory or provides limits ;o)
Er... may I suggest ratio's as a data format? It won't work for sqrt(2)
or PI, but it can easily store
On Thu, Mar 22, 2001 at 11:14:53AM -0800, Hong Zhang wrote:
> Please not fight on wording. For most encodings I know of, the concept of
> normalization does not even exist.
*boggle*. I don't think we're talking about the same Unicode.
> What is your definition of normalization?
Well, either ca
At 11:14 AM 03-22-2001 -0800, Hong Zhang wrote:
>Please not fight on wording. For most encodings I know of, the concept of
>normalization does not even exist. What is your definition of normalization?
To me, the usual definition of "normalization' is conversion of something
into a standard form
> > The normalization has something to do with encoding. If you compare two
> > strings with the same encoding, of course you don't have to care about
it.
>
> Of course you do. Think about it.
I said "you don't have to". You can use "==" for codepoint comparison, and
something like "Normalizer.co
On Tue, Mar 06, 2001 at 01:21:20PM -0800, Hong Zhang wrote:
> The normalization has something to do with encoding. If you compare two
> strings with the same encoding, of course you don't have to care about it.
Of course you do. Think about it.
If I'm comparing "(Greek letter lower case alpha wi
At 01:01 AM 3/10/2001 +0100, Paolo Molaro wrote:
>On 03/05/01 Dan Sugalski wrote:
> > =item Arbitrary precision integers
> >
> > Big integers, or bigints, are arbitrary-length integer numbers. The
> > only limit to the number of digits in a bigint is the lesser of the
> > amount of memory availabl
On 03/05/01 Dan Sugalski wrote:
> =item Arbitrary precision integers
>
> Big integers, or bigints, are arbitrary-length integer numbers. The
> only limit to the number of digits in a bigint is the lesser of the
> amount of memory available or the maximum value that can be
> represented by a C. Th
> > Most won't, honestly. At a guess, 90% of perl's current userbase doesn't
> > care about Unicode for any reason other than XML,
The next version of Gtk+ will use utf8. Qt use unicode already. Tk
will probably move in the same direction if it doesn't do it already.
So most user interface applic
As I see it, there will be 3 types of access to bigint/nums.
1) there is the internal implementation of the PMC types associated
with them. This is where all the messy code gets hidden (assembler
optimations, register length-specific code etc).
2) PDD 2 requires that all PMC types return their i
At 03:03 PM 3/8/2001 -0800, Hong Zhang wrote:
>For bigint, we definite need a highly portable implementation.
>People can do platform specific optimization on their own later.
>We should settle the generic implementation first, with proper
>encapsulation.
Care to start one? I'm about to start th
For bigint, we definite need a highly portable implementation.
People can do platform specific optimization on their own later.
We should settle the generic implementation first, with proper
encapsulation.
Hong
> >Do we need to settle on anything - can it vary by platform so that 64 bit
> >plat
At 10:28 PM 3/8/2001 +, Nicholas Clark wrote:
>On Thu, Mar 08, 2001 at 04:28:48PM -0500, Dan Sugalski wrote:
> > At 08:43 PM 3/8/2001 +, Nicholas Clark wrote:
>
> > I think most processors that do 32x32 multiply provide a way to get the
> > 64-bit result. Whether *we* can is another matter
On Thu, Mar 08, 2001 at 04:28:48PM -0500, Dan Sugalski wrote:
> At 08:43 PM 3/8/2001 +, Nicholas Clark wrote:
> I think most processors that do 32x32 multiply provide a way to get the
> 64-bit result. Whether *we* can is another matter, of course, but if
> platform folks want to drop to ass
At 08:43 PM 3/8/2001 +, Nicholas Clark wrote:
>On Thu, Mar 08, 2001 at 11:31:06AM -0800, Hong Zhang wrote:
> > > Looks like they do operations with 16-bit integers. I'd as soon go with
> > > 32-bit ones--wastes a little space, but should be faster. (Except
> where we
> > > should shift to 64-
At 03:35 PM 3/8/2001 -0500, Bryan C. Warnock wrote:
>On Thursday 08 March 2001 11:43, Dan Sugalski wrote:
> > It probably ought to be left undefined, in case we switch implementations
> > later.
>
>Er, except, aren't you (we) supposed to be defining the implementation?
>I thought the hand-waving p
At 08:34 PM 3/8/2001 +, Nicholas Clark wrote:
>On Thu, Mar 08, 2001 at 01:55:57PM -0500, Dan Sugalski wrote:
> > At 06:49 PM 3/8/2001 +, Nicholas Clark wrote:
> > >On Thu, Mar 08, 2001 at 11:43:31AM -0500, Dan Sugalski wrote:
> > > > I was thinking maybe (length/4)*31-bit 2s complement to
On Thu, Mar 08, 2001 at 11:31:06AM -0800, Hong Zhang wrote:
> > Looks like they do operations with 16-bit integers. I'd as soon go with
> > 32-bit ones--wastes a little space, but should be faster. (Except where we
> > should shift to 64-bit words)
>
> Using 32/31-bit requires general support of
On Thursday 08 March 2001 11:43, Dan Sugalski wrote:
> It probably ought to be left undefined, in case we switch implementations
> later.
Er, except, aren't you (we) supposed to be defining the implementation?
I thought the hand-waving period was over, and we're doing specifications.
If there
On Thu, Mar 08, 2001 at 01:55:57PM -0500, Dan Sugalski wrote:
> At 06:49 PM 3/8/2001 +, Nicholas Clark wrote:
> >On Thu, Mar 08, 2001 at 11:43:31AM -0500, Dan Sugalski wrote:
> > > I was thinking maybe (length/4)*31-bit 2s complement to make portable
> > > overflow detection easier, but that w
> Looks like they do operations with 16-bit integers. I'd as soon go with
> 32-bit ones--wastes a little space, but should be faster. (Except where we
> should shift to 64-bit words)
Using 32/31-bit requires general support of 64-bit arithmetics, for shift
and multiply. Without it, we have to use
At 10:49 AM 3/8/2001 -0800, Hong Zhang wrote:
> > I was thinking maybe (length/4)*31-bit 2s complement to make portable
> > overflow detection easier, but that would be only if there wasn't a good C
> > library for this available to snag.
>
>I believe Python uses (length/2)*15-bit 2's complement r
At 06:49 PM 3/8/2001 +, Nicholas Clark wrote:
>On Thu, Mar 08, 2001 at 11:43:31AM -0500, Dan Sugalski wrote:
> > I was thinking maybe (length/4)*31-bit 2s complement to make portable
> > overflow detection easier, but that would be only if there wasn't a good C
> > library for this available t
> I was thinking maybe (length/4)*31-bit 2s complement to make portable
> overflow detection easier, but that would be only if there wasn't a good C
> library for this available to snag.
I believe Python uses (length/2)*15-bit 2's complement representation.
Because bigint and bitnum are complica
On Thu, Mar 08, 2001 at 11:43:31AM -0500, Dan Sugalski wrote:
> I was thinking maybe (length/4)*31-bit 2s complement to make portable
> overflow detection easier, but that would be only if there wasn't a good C
> library for this available to snag.
The only portable integer overflow in ANSI C i
At 03:00 PM 3/8/2001 +, David Mitchell wrote:
> > The C structure that represents a bigint is:
> >
> >struct bigint {
> > void *num_buffer;
> > UV length;
> > IV exponent;
> > UV flags;
> >}
> >
>[snip]
> > The C pointer points to the buffer holding the actual
> >
> The C structure that represents a bigint is:
>
>struct bigint {
> void *num_buffer;
> UV length;
> IV exponent;
> UV flags;
>}
>
[snip]
> The C pointer points to the buffer holding the actual
> number, C is the length of the buffer, C is the base
> 10 exponent for
At 01:21 PM 3/6/2001 -0800, Hong Zhang wrote:
> > Unless I really, *really* misread the unicode standard (which is
>distinctly
> > possible) normalization has nothing to do with encoding,
>
>I understand what you are trying to say. But it is not very easy in
>practice. The normalization has someth
> Unless I really, *really* misread the unicode standard (which is
distinctly
> possible) normalization has nothing to do with encoding,
I understand what you are trying to say. But it is not very easy in
practice.
The normalization has something to do with encoding. If you compare two
strings
wi
At 04:14 PM 3/5/2001 -0800, Hong Zhang wrote:
> > >Here is an example, "re`sume`" takes 6 characters in Latin-1, but
> > >could take 8 characters in Unicode. All Perl functions that directly
> > >deal with character position and length will be sensitive to encoding.
> > >I wonder how we should han
> >Here is an example, "re`sume`" takes 6 characters in Latin-1, but
> >could take 8 characters in Unicode. All Perl functions that directly
> >deal with character position and length will be sensitive to encoding.
> >I wonder how we should handle this case.
>
> My first inclination is to force n
At 12:01 PM 3/5/2001 -0800, Hong Zhang wrote:
> >struct perl_string {
> > void *string_buffer;
> > UV length;
> > UV allocated;
> > UV flags;
> >}
> >
> > The low three bits of the flags field is reserved for the type of the
> > string. The various types are:
> >
> > =o
>struct perl_string {
> void *string_buffer;
> UV length;
> UV allocated;
> UV flags;
>}
>
> The low three bits of the flags field is reserved for the type of the
> string. The various types are:
>
> =over 4
>
> =item BINARY (0)
>
> =item ASCII (1)
>
> =item EBCDIC
At 01:38 PM 3/2/2001 -0800, Hong Zhang wrote:
> > I was hoping to get us something that was guaranteed to hold an integer,
>no
> > matter what it was, so you could do something like:
> >
> >struct thingie {
> > UV type;
> > INT my_int;
> >}
>
>What is the purpose of doing this?
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> One needs to specify *which* PDP is the target. The PDP-11 was the
DS> most popular of the bunch, and it's a 16-bit machine. One of the
DS> TOPS machines was 36 bit, IIRC, with either 7 or 9 bit
DS> chars. (Can't remember which)
> I was hoping to get us something that was guaranteed to hold an integer,
no
> matter what it was, so you could do something like:
>
>struct thingie {
> UV type;
> INT my_int;
>}
What is the purpose of doing this? The SV is guaranteed to hold anything.
Why we need a type that
At 02:02 PM 3/2/2001 -0600, Jarkko Hietaniemi wrote:
>On Fri, Mar 02, 2001 at 12:05:59PM -0800, Hong Zhang wrote:
> > > >at some
> > > >points it becomes necessary to have an unsigned type for "the largest
> > > >integer" which in this case would be 72 bits.
> > > >[and on a machine with nothing l
At 12:05 PM 3/2/2001 -0800, Hong Zhang wrote:
> > >at some
> > >points it becomes necessary to have an unsigned type for "the largest
> > >integer" which in this case would be 72 bits.
> > >[and on a machine with nothing larger than 32 will be 32]
> >
> > Sure. The size of an INT will probably be
On Fri, Mar 02, 2001 at 12:05:59PM -0800, Hong Zhang wrote:
> > >at some
> > >points it becomes necessary to have an unsigned type for "the largest
> > >integer" which in this case would be 72 bits.
> > >[and on a machine with nothing larger than 32 will be 32]
> >
> > Sure. The size of an INT wil
> >at some
> >points it becomes necessary to have an unsigned type for "the largest
> >integer" which in this case would be 72 bits.
> >[and on a machine with nothing larger than 32 will be 32]
>
> Sure. The size of an INT will probably be either 32 or 64 bits, depending
> both on the size of an I
At 07:17 PM 3/2/2001 +, Nicholas Clark wrote:
>On Fri, Mar 02, 2001 at 01:40:40PM -0500, Dan Sugalski wrote:
> > At 01:36 PM 3/2/2001 -0500, Andy Dougherty wrote:
>
> > >Do you also want an unsigned variant? (trying to spare Nick some of
> > >the sign preservation madness he's currently battl
On Fri, Mar 02, 2001 at 01:40:40PM -0500, Dan Sugalski wrote:
> At 01:36 PM 3/2/2001 -0500, Andy Dougherty wrote:
> >Do you also want an unsigned variant? (trying to spare Nick some of
> >the sign preservation madness he's currently battling in perl5.)
>
> Well, we've got an unsigned version of
At 01:36 PM 3/2/2001 -0500, Andy Dougherty wrote:
>On Fri, 2 Mar 2001, Dan Sugalski wrote:
>
> > =head2 Intger data types
> >
> > Integer data types are generically referred to as Cs. There is an
> > C typedef that is guaranteed to hold any integer type.
>
>[gazing into crystal ball . . . ] I pred
On Fri, 2 Mar 2001, Dan Sugalski wrote:
> =head2 Intger data types
>
> Integer data types are generically referred to as Cs. There is an
> C typedef that is guaranteed to hold any integer type.
[gazing into crystal ball . . . ] I predict some header somewhere is going
to already #define "INT".
47 matches
Mail list logo
