Martin D Kealey wrote:
> On Thu, 26 Feb 2009, Jon Lang wrote:
>> asin is not the inverse function of sin, although it's probably as close
>> as you can get. And even there, some sort of compiler optimization could
>> potentially be done, replacing the composition of asin and sin (both of
>> which
On Thu, 26 Feb 2009, Jon Lang wrote:
> asin is not the inverse function of sin, although it's probably as close
> as you can get. And even there, some sort of compiler optimization could
> potentially be done, replacing the composition of asin and sin (both of
> which have the potential to intensi
On Feb 26, 2009, at 14:27 , Jon Lang wrote:
Jon Lang wrote:
Brandon S. Allbery wrote:
Jon Lang wrote:
I'm not sold on the notion that Num should represent a range of
values
Arguably a range is the only sane meaning of a floating point number.
Perhaps; but a Num is not necessarily a floatin
Jon Lang wrote:
> TSa wrote:
>> Jon Lang wrote:
>>>
>>> �...@a[50%] # accesses the middle item in the list, since Whatever is
>>> set to the length of the list.
>>
>> I don't understand what you mean with setting Whatever. Whatever is
>> a type that mostly behaves like Num and is used for overloa
I don't know how relevant this is; but this sounds like the sort of
optimization that pure functional programming allows for - that is, if
the compiler ever sees a call like asin(sin($x)), it might optimize
the code by just putting $x in there directly, and bypassing both the
sin and asin calls -
On 2009 Feb 26, at 13:00, Jon Lang wrote:
I'm not sold on the notion that Num should represent a range of values
Arguably a range is the only sane meaning of a floating point number.
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimd
Daniel Ruoso wrote:
> Em Qui, 2009-02-26 às 17:01 +0100, TSa escreveu:
>> $y.error = 0.001;
>> $x ~~ $y;
>
> Looking at this I just started wondering... why wouldn't that be made
> with:
>
> my $y = 10 but Imprecise(5%);
> $x ~~ $y;
That's not bad; I like it.
--
Jonathan "Dataweaver"
TSa wrote:
> HaloO,
>
> Jon Lang wrote:
>>
>> �...@a[50%] # accesses the middle item in the list, since Whatever is
>> set to the length of the list.
>
> I don't understand what you mean with setting Whatever. Whatever is
> a type that mostly behaves like Num and is used for overloaded
> postcirc
Em Qui, 2009-02-26 às 17:01 +0100, TSa escreveu:
> $y.error = 0.001;
> $x ~~ $y;
Looking at this I just started wondering... why wouldn't that be made
with:
my $y = 10 but Imprecise(5%);
$x ~~ $y;
daniel
HaloO,
Jon Lang wrote:
@a[50%] # accesses the middle item in the list, since Whatever is
set to the length of the list.
I don't understand what you mean with setting Whatever. Whatever is
a type that mostly behaves like Num and is used for overloaded
postcircumfix:<[ ]>:(Array @self: Whate
HaloO,
Larry Wall wrote:
That seems a bit ugly though. Another way would be to define ± as
simple half-open Range and then overload comparison:
multi sub infix:<==>(Num $x,Range $r) {
$x == any($r.minmax);
}
This is strange. Having 1 == 1..3 and 3 == 1..3 as true is
not what
On Wed, Feb 25, 2009 at 02:34:50PM -0800, Jon Lang wrote:
: Mark J. Reed wrote:
: > I do quite like the magical postfix %, but I wonder how far it should
: > go beyond ±:
: >
: > $x += 5%; # becomes $x += ($x * .05)? Or maybe $x *= 1.05 ?
: > $x * 5%; # becomes $x * .05 ?
:
: If it works wit
At 13:58 -0500 2/25/09, Mark J. Reed wrote:
I do quite like the magical postfix %, but I wonder how far it should
go beyond ±:
$x += 5%; # becomes $x += ($x * .05)? Or maybe $x *= 1.05 ?
$x * 5%; # becomes $x * .05 ?
For ratio-like comparisons for effective equality of floats some
though
Mark J. Reed wrote:
> I do quite like the magical postfix %, but I wonder how far it should
> go beyond ±:
>
> $x += 5%; # becomes $x += ($x * .05)? Or maybe $x *= 1.05 ?
> $x * 5%; # becomes $x * .05 ?
If it works with ±, it ought to work with + and -. Rule of thumb: if
there's no easy way
I think the use of % for the modulus operator is too deeply ingrained
to repurpose its infix incarnation.
I do quite like the magical postfix %, but I wonder how far it should
go beyond ±:
$x += 5%; # becomes $x += ($x * .05)? Or maybe $x *= 1.05 ?
$x * 5%; # becomes $x * .05 ?
HaloO,
Doug McNutt wrote:
Thinking about what I actually do. . .
A near equal test of a float ought to be a fractional error based on the
current value of the float.
$x tested for between $a*(1.0 + $errorfraction) and $a*(1.0 -
$errorfraction)
I strongly agree that checking relative erro
On Wed, Feb 25, 2009 at 07:03:27PM +1300, Martin D Kealey wrote:
: On Wed, 25 Feb 2009, I wrote:
: > $y + ±5 # same as ($y - 5) | ($y + 5) (also same as $y - ±5)
: > $y ± 5# same as ($y - 5) .. ($y + 5)
That seems a little cheesy to me.
: A further question: should such ranges be [clo
On Wed, 25 Feb 2009, I wrote:
> $y + ±5 # same as ($y - 5) | ($y + 5) (also same as $y - ±5)
> $y ± 5# same as ($y - 5) .. ($y + 5)
A further question: should such ranges be [closed], (open) or [half-open)?
I would argue for half-open because then exactly one of a set of consecutive
r
On Tue, 24 Feb 2009, Jon Lang wrote:
> $y ± 5 # same as ($y - 5) | ($y + 5)
> $y within 5 # same as ($y - 5) .. ($y + 5)
I suspect that we're running against Huffman here, given the likely
usage -- ranges *should* be used at pretty much every floating point
"equality" test, whereas "any(-
On 2009 Feb 23, at 8:34, Ruud H.G. van Tol wrote:
Martin D Kealey wrote:
Ah, we want a noun that isn't readily confused as an adjective.
Suitable terms might include: Instant Jiffy Juncture Moment
Occasion Snap Tick ...
Once :)
"Then"?
--
brandon s. allbery [solaris,freebsd,perl,pugs,hask
On Tue, Feb 24, 2009 at 04:54:35PM -0800, Jon Lang wrote:
: Half-baked idea here: could we somehow use some dwimmery akin to
: Whatever magic to provide some meaning to a postfix:<%> operator?
: Something so that you could say:
:
: $x within 5%
:
: And it would translate it to:
:
: $x within
Doug McNutt wrote:
> Thinking about what I actually do. . .
>
> A near equal test of a float ought to be a fractional error based on the
> current value of the float.
>
> $x tested for between $a*(1.0 + $errorfraction) and $a*(1.0 -
> $errorfraction)
>
> If you're dealing with propagation of error
Thinking about what I actually do. . .
A near equal test of a float ought to be a fractional error based on
the current value of the float.
$x tested for between $a*(1.0 + $errorfraction) and $a*(1.0 - $errorfraction)
If you're dealing with propagation of errors during processing of
data th
On Tue, Feb 24, 2009 at 1:39 PM, Daniel Ruoso wrote:
> Em Ter, 2009-02-24 às 13:34 -0800, Jon Lang escreveu:
>> Daniel Ruoso wrote:
>> > if $y ~~ [..] $x ± $epsilon {...}
>> Junctions should not return individual values in list context,
>
> It is not the junction that is returning the individual
TSa wrote:
> Larry Wall wrote:
>> So it might be better as a (very tight?) operator, regardless of
>> the spelling:
>>
>> $x ~~ $y within $epsilon
>
> This is a pretty add-on to smartmatch but I still think
> we are wasting a valueable slot in the smartmatch table
> by making numeric $x ~~ $y s
Em Ter, 2009-02-24 às 13:34 -0800, Jon Lang escreveu:
> Daniel Ruoso wrote:
> > if $y ~~ [..] $x ± $epsilon {...}
> Junctions should not return individual values in list context,
It is not the junction that is returning the individual values, but the
infix:<±> operator...
daniel
Daniel Ruoso wrote:
> What about...
>
> if $x ~~ [..] $x ± $epsilon {...}
>
> That would mean that $x ± $epsilon in list context returned each value,
> where in scalar context returned a junction, so the reduction operator
> could do its job...
(I'm assuming that you meant something like "if $y ~
On Tue, 2009-02-24 at 12:31 -0800, Jon Lang wrote:
> $y ± 5 # same as ($y - 5) | ($y + 5)
> $y within 5 # same as ($y - 5) .. ($y + 5)
Oh, that's just beautiful.
-'f
On Tuesday, 24. February 2009 17:59:31 Larry Wall wrote:
> So it might be better as a (very tight?) operator, regardless of
> the spelling:
>
> $x ~~ $y within $epsilon
This is a pretty add-on to smartmatch but I still think
we are wasting a valueable slot in the smartmatch table
by making num
Em Ter, 2009-02-24 às 08:59 -0800, Larry Wall escreveu:
> I'm using ± more in the engineering sense than the mathematical
> sense.
What about...
if $x ~~ [..] $x ± $epsilon {...}
That would mean that $x ± $epsilon in list context returned each value,
where in scalar context returned a junctio
Larry Wall wrote:
> So it might be better as a (very tight?) operator, regardless of
> the spelling:
>
> $x ~~ $y within $epsilon
I like this: it's readable and intuitive. As well, it leaves ±
available for use in its mathematical sense.
> For what it's worth, ± does happen to be in Latin-1,
On Mon, Feb 23, 2009 at 11:54:44PM -0600, Chris Dolan wrote:
> On Feb 23, 2009, at 11:16 PM, Larry Wall wrote:
>
>> if $x ~~ $y ± $epsilon {...}
>>
>> where infix:<±> turns the single value into a range for the
>> smartmatch.
>
>
> That's very cool. However, my first impression is that "$y ±
On Mon, Feb 23, 2009 at 5:01 PM, Graham Barr wrote:
> Juncture
As has already been pointed out, that has extremely high potential for
being confused with Junctions.
--
Mark J. Reed
On Feb 23, 2009, at 3:56 PM, mark.a.big...@comcast.net wrote:
Instant
Moment
Point
PointInTime
Timestamp
Event
Jiffy
Time
Juncture
On Feb 23, 2009, at 11:16 PM, Larry Wall wrote:
if $x ~~ $y ± $epsilon {...}
where infix:<±> turns the single value into a range for the
smartmatch.
That's very cool. However, my first impression is that "$y ±
$epsilon" maps more naturally to "any($y-$epsilon, $y+$epsilon)" than
t
On Mon, Feb 23, 2009 at 09:08:39PM -0700, David Green wrote:
> On 2009-Feb-23, at 10:09 am, TSa wrote:
>> I also think that time and numbers in general should be treated in
>> a fuzzy way by smart match.
>
> My thought is to have == take a :within adverb, at least for imprecise
> types like Num,
On 2009-Feb-23, at 10:09 am, TSa wrote:
I also think that time and numbers in general should be treated in
a fuzzy way by smart match.
My thought is to have == take a :within adverb, at least for imprecise
types like Num, that could be used to specify how close values need to
come in order
On Mon, Feb 23, 2009 at 4:56 PM, wrote:
> Instant
Most apropos. Classes are nouns, so the adjectival meaning doesn't
cause a conflict, IMHO: "an instant" has nothing to do with instant
coffee.
> Moment
Also apropos, and with a history in the field (Calendrical
Calculations uses "moment" for val
Instant
Moment
Point
PointInTime
Timestamp
Event
Jiffy
Time
Mark
Biggar%0D%0Amark%40biggar.org%0D%0Amark.a.biggar%40comcast.net%0D%0Ambiggar%40paypal.com
On Mon, 23 Feb 2009, TSa wrote:
HaloO,
Eirik Berg Hanssen wrote:
Suitable terms might include: Instant Jiffy Juncture Moment Occasion Snap
Tick ...
Time::Point.
Of course, being Norwegian, I may be biased. ;-)
Same here in German, we have "Zeitpunkt" which literally means
timepoint. B
On Mon, 23 Feb 2009, Ruud H.G. van Tol wrote:
Martin D Kealey wrote:
Ah, we want a noun that isn't readily confused as an adjective.
Suitable terms might include: Instant Jiffy Juncture Moment Occasion Snap
Tick ...
Once :)
Hmm. Temporal::OnceUponATime :).
--
HaloO,
Eirik Berg Hanssen wrote:
Suitable terms might include: Instant Jiffy Juncture Moment Occasion Snap Tick
...
Time::Point.
Of course, being Norwegian, I may be biased. ;-)
Same here in German, we have "Zeitpunkt" which literally means
timepoint. But note that clock time is "Uhrze
Martin D Kealey writes:
> On Mon, 23 Feb 2009, Timothy S. Nelson wrote:
>> Hmm. Ah, I can see why it's ambiguous. For those who missed it, think of
>> what "instant" means in the context of "Instant coffee". I think I still
>> slightly prefer "instant", but I don't mind much any more :).
>
>
Martin D Kealey wrote:
Ah, we want a noun that isn't readily confused as an adjective.
Suitable terms might include: Instant Jiffy Juncture Moment Occasion Snap Tick
...
Once :)
--
Ruud
On Mon, 23 Feb 2009, Martin D Kealey wrote:
On Mon, 23 Feb 2009, Timothy S. Nelson wrote:
Renamed Temporal::Instant to Temporal::DateTime
Hmm. We had some mailing list discussion about this, and agreed on
Instant. I'd like to see your reasons in favour of DateTime.
Because DateTim
On Mon, 23 Feb 2009, Timothy S. Nelson wrote:
> > > > Renamed Temporal::Instant to Temporal::DateTime
> > >
> > > Hmm. We had some mailing list discussion about this, and agreed on
> > > Instant. I'd like to see your reasons in favour of DateTime.
> >
> > Because DateTime makes sense and is a c
On Fri, 20 Feb 2009, Dave Rolsky wrote:
On Fri, 20 Feb 2009, Timothy S. Nelson wrote:
Format specifiers - this could come from locales (CLDR specifies this)
or strftime, but again, it's more complicated than is needed
[snip]
Added iso8601 output for every role, and made that the
stringificat
On Fri, 20 Feb 2009, Dave Rolsky wrote:
> > > Renamed Temporal::Instant to Temporal::DateTime
> >
> > Hmm. We had some mailing list discussion about this, and agreed on
> > Instant. I'd like to see your reasons in favour of DateTime.
>
> Because DateTime makes sense and is a clear description of
On Fri, 20 Feb 2009, Timothy S. Nelson wrote:
Format specifiers - this could come from locales (CLDR specifies this)
or strftime, but again, it's more complicated than is needed
[snip]
Added iso8601 output for every role, and made that the
stringification. ISO8601 is unambiguous world-wide, ea
On Fri, 20 Feb 2009, Timothy S. Nelson wrote:
+role Temporal::DateTime {
+has Temporal::Date $!date handles ;
Can't do this, I think; this would require an instance of
Temporal::Date, which is a role and can't be instantiated. That's why I was
using "does" instead. I don't know
On Thu, 19 Feb 2009, pugs-comm...@feather.perl6.nl wrote:
Author: autarch
Date: 2009-02-19 19:14:48 +0100 (Thu, 19 Feb 2009)
New Revision: 25445
Modified:
docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
This is a very drastic revision (hopefully this won't turn into a revert war ;)
I
51 matches
Mail list logo
