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 I
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:
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
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
postcircumfix:[
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 Lang
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
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 -
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 overloaded
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
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 have the
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
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 ?
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 to
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
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 with ±,
On Feb 23, 2009, at 3:56 PM, mark.a.big...@comcast.net wrote:
Instant
Moment
Point
PointInTime
Timestamp
Event
Jiffy
Time
Juncture
On Mon, Feb 23, 2009 at 5:01 PM, Graham Barr gb...@pobox.com wrote:
Juncture
As has already been pointed out, that has extremely high potential for
being confused with Junctions.
--
Mark J. Reed markjr...@gmail.com
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 ± $epsilon
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
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
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 ~~ [..]
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
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 simply mean
On Tue, Feb 24, 2009 at 1:39 PM, Daniel Ruoso dan...@ruoso.com 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
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
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 errors during
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
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
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
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
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
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 Uhrzeit
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 :).
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.
On Mon, Feb 23, 2009 at 4:56 PM, mark.a.big...@comcast.net 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
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 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, that
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 what the
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
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 clear description
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
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,
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 ;)
On Fri, 20 Feb 2009, Timothy S. Nelson wrote:
+role Temporal::DateTime {
+has Temporal::Date $!date handles year month day day-of-week;
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
44 matches
Mail list logo
