On Fri, Mar 23, 2012 at 07:14:51PM +1100, Damian Conway wrote:
: For example:
:
: 1, 1.0001, 1.0002 ... *
:
: won't deduce a correct arithmetic sequence either (on most hardware).
Actually, that one works fine in both niecza and rakudo, since those are Rats.
Larry
> Actually, that one works fine in both niecza and rakudo, since those are Rats.
Oh, that's good to hear.
It doesn't change my underlying argument however. Any operations
performed on genuine floats are going to lose precision, and if we're
using such operations to infer relationships (such as eq
On Mar 24, 2012, at 5:26 PM, Damian Conway wrote:
>> Actually, that one works fine in both niecza and rakudo, since those are
>> Rats.
>
> Oh, that's good to hear.
>
> It doesn't change my underlying argument however. Any operations
> performed on genuine floats are going to lose precision, an
On Sat, Mar 24, 2012 at 06:16:58PM -0700, Jonathan Lang wrote:
> IMHO: if we're going to take loss of precision into account, we should do so
> explicitly. I'm a bit rusty, so forgive me if I misuse the terminology: if a
> number has an epsilon, the epsilon should be attached to it as a trait so
On Mar 24, 2012, at 6:36 PM, Stefan O'Rear wrote:
> On Sat, Mar 24, 2012 at 06:16:58PM -0700, Jonathan Lang wrote:
>> IMHO: if we're going to take loss of precision into account, we should do so
>> explicitly. I'm a bit rusty, so forgive me if I misuse the terminology: if
>> a number has an eps
On 2012-March-23, at 12:01 am, Damian Conway wrote:
> [...] we ought to allow for the inevitable loss of significant digits within
> the two preliminary division ops, and therefore compare the results with an
> suitably larger epsilon.
> That would not only be computational more justifiable, I su
On 2012-March-21, at 6:38 pm, Daniel Carrera wrote:
> The idea of smart-matching a function just doesn't quite fit with my brain. I
> can memorize the fact that smart-matching 7 and &foo means evaluating foo(7)
> and seeing if the value is true, but I can't say I "understand" it.
Maybe it just n
On 03/23/2012 09:14 AM, Damian Conway wrote:
>> it means we cannot do the same fuzziness for the endpoint,
>
> Except that we will be encouraging people to use: * >= $END
> as their standard endpoint pattern, which will provide
> most of the necessary fuzz.
and which will still surprise those p
On 03/25/2012 05:59 AM, David Green wrote:
> On 2012-March-23, at 12:01 am, Damian Conway wrote:
>> [...] we ought to allow for the inevitable loss of significant digits within
>> the two preliminary division ops, and therefore compare the results with an
>> suitably larger epsilon.
>> That wou
> At least in #perl6 I've never seen anybody try to write an auto-deduced
> sequence, and fail because of floating-point errors.
Except for Martin's 1, sqrt(2), 2...8
But, yes, the widespread use of Rats rather than Nums
means only the edgiest of edge-cases fails. And as you get
an explicit Failu
10 matches
Mail list logo
