Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-26 Thread Jon Lang
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-26 Thread Martin D Kealey
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-26 Thread Brandon S. Allbery KF8NH
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-26 Thread Jon Lang
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-26 Thread Doug McNutt
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 -

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-26 Thread Brandon S. Allbery KF8NH
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-26 Thread Jon Lang
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"

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-26 Thread Jon Lang
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-26 Thread Daniel Ruoso
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-26 Thread TSa
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-26 Thread TSa
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-25 Thread Larry Wall
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-25 Thread Doug McNutt
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-25 Thread Jon Lang
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-25 Thread Mark J. Reed
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 ?

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-25 Thread TSa
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-24 Thread Larry Wall
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-24 Thread Martin D Kealey
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-24 Thread Martin D Kealey
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(-

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-24 Thread Larry Wall
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-24 Thread Jon Lang
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-24 Thread Doug McNutt
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-24 Thread Jon Lang
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-24 Thread Jon Lang
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-24 Thread Daniel Ruoso
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-24 Thread Jon Lang
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 ~

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-24 Thread Geoffrey Broadwell
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-24 Thread TSa (Thomas Sandlaß)
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-24 Thread Daniel Ruoso
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-24 Thread Jon Lang
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,

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-24 Thread Larry Wall
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 ±

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-23 Thread Chris Dolan
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

Re: Comparing inexact values (was "Re: Temporal changes")

2009-02-23 Thread Larry Wall
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,

Comparing inexact values (was "Re: Temporal changes")

2009-02-23 Thread David Green
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