Yary,
There already is a Perl 6 continue fractions module. Spoiler alert: it
doesn't work in the least. But I'd be happy to give you a commit bit.
I don't think we should even begin to think about including something like
that in the Perl 6 core before we have a complete, working implementation
Thinking over my programming career, there were a few occasions I had to
spend time working around floating point errors, and it was a nuisance.
There were even fewer times when I worked with transcendental numbers-
programs dealing with geometry or tones or logarithmic scales- and those
times, flo
-setting-library/Numeric.pod
Log Message:
---
Define .narrow method to narrow numeric types
Can narrow either Rat or Num to Int, for instance.
Resolves #47.
ate")
>
> I can't just add the method to the Complex class, because then the
> Vector code would fail ("method not found") for all non-complex
> numeric types (for which conjugation is an identity operation).
--
Will "Coke" Coleda
ot;)
I can't just add the method to the Complex class, because then the
Vector code would fail ("method not found") for all non-complex
numeric types (for which conjugation is an identity operation).
Mike wrote:
>
> >: (B) Need to know the root of the numeric types
>
> If it isn't obvious to everyone else, the main (only?) reason to care
> about this is when checking/specifying context/args. Assume num means
> a double-precision float.
>
> Simply put: (
On Monday, November 18, 2002, at 04:54 PM, Larry Wall wrote:
: (B) Need to know the root of the numeric types
:
: Option 1:
: numeric (mostly abstract base class)
: - num
: - int
:
: Option 2:
:
: num (floating point 'num' is the
auto-infer 8bit
:
: Option 2: specify as type
:
: my u_long $a;# standard C type
: my long_double $c;
:
: Option 3: ???
:
: (See p6d discussion, "Numeric Types")
These options are not mutually exclusive in the presence of type
aliasing. However, my overall
On Monday, November 18, 2002, at 01:33 PM, Dave Whipp wrote:
my int $a is range(1000..1255) is unchecked; # auto-infer 8bit
Just to clarify: I think of the latter (C) for efficient
packing into arrays (e.g. a 5-bit range can be packed efficiently,
even though there is no 5-bit c-type): b
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote
> (A) How shall C-like primitive types be specified, e.g. for binding
> to/from C library routines, etc?
>
>Option 1: specify as property
>
> my numeric $a is ctype("unsigned long int"); # standard C type
> my numeric $b is ctype("my_int32"
("my_int32"); # user-defined
my numeric $c is ctype("long double");
my int $a is range(1000..1255) is unchecked; # auto-infer 8bit
Option 2: specify as type
my u_long $a;# standard C type
my long_double $c;
Option 3: ???
(See p6d dis
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote
>[...]
> So if you *knew* you were dealing with
> 16-bit unsigned integers, you could say
>
> my uint16 @numarray;
>
> and it would generate the optimal code for such an array. You could
> instead say:
>
> my Int @numarray is ctype("unsigned short int"
On Friday, November 15, 2002, at 01:10 AM, Dave Whipp wrote:
I still don't understand why we want to go to all this hassle of
completing a vast list primitives to support mappings onto languages
and architectures that have yet to be invented. I still prefer to keep
things simple:
my Number $a
Dave Whipp writes:
> [EMAIL PROTECTED] wrote:
> > Dave Whipp writes:
> > >
> > > You can rename the types if you want; but properties are a better
> > > representation of constraints than type names: more precise, and more
> > > flexible.
> > >
> >
> > but types *are* properties
[EMAIL PROTECTED] wrote:
Dave Whipp writes:
>
> You can rename the types if you want; but properties are a better
> representation of constraints than type names: more precise, and more
> flexible.
>
but types *are* properties .
arcadi
True :-(
But I think my examples somehow withst
Dave Whipp writes:
>
> You can rename the types if you want; but properties are a better
> representation of constraints than type names: more precise, and more
> flexible.
>
but types *are* properties .
arcadi
Michael Lazzaro wrote:
Does someone from internals want to take on the task of finalizing this
list? We need to decide if we want to support none, some, or all of
these types/aliases.
-
The Full List of Numeric Types
In addition to the standard int and num, there are a great number of
Does someone from internals want to take on the task of finalizing this
list? We need to decide if we want to support none, some, or all of
these types/aliases.
-
The Full List of Numeric Types
In addition to the standard int and num, there are a great number of
other numeric types
Looks good.
I'll rewrite the literals section to match this better outline.
-angel
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Wed, 13 Nov 2002 11:01:26 -0800
> From: Michael Lazzaro <[EMAIL PROTECTED]>
>
> - converting numbers to strings
> - writing a number as a string
> (what the rules are for how it will look)
> - writing a number as a f
agment.
There are a number of topics which must be covered when exploring how
basic typed/untyped numbers will work in Perl6. At minimum:
-
- introducing the basic numeric types, C, C, C
- literal values (Angel's doc)
- integer and decimal literals
- scientific/exponent
21 matches
Mail list logo
