Re: Language design

2015-07-13 Thread Jan Ingvoldstad
On Tue, Jul 14, 2015 at 12:04 AM, Michael Zedeler 
wrote:
>
> So far, almost every other language has behaved this way, and it has
> worked. I can see that Rats do solve a problem, but if you'd claim that it
> is very severe then I'd disagree. This is a minor nuisance that I'd only
> pay a small price to fix.
>

People who use your lovely example – spreadsheets – tend to disagree.

There was a LOT of noise about how Excel handled numbers in a very
surprising manner, every time a "new" problem came up.

There are a gazillion articles about how to avoid it, and people who deal
with spreadsheets spend inordinate amounts of time to get around it.

Or they take the performance hit for asking for the precision of numbers
"as displayed".

For more information, please see here:

https://support.microsoft.com/en-us/kb/78113

The "minor nuisance" is not so minor out there in the real world, where
people use actual applications where they _expect_ WYSIWYG numbers.

Now, what Rats solve for us programmers, is that it makes it easier for us
to avoid these pitfalls, and thereby makes it easier for us to cater for
our users.
-- 
Jan


Re: Language design

2015-07-13 Thread Michael Zedeler
 Darren Duncan wrote 

> On 2015-06-16 2:15 PM, The Sidhekin wrote:
> > On Tue, Jun 16, 2015 at 10:52 PM, Michael Zedeler  
> > wrote:
> > ...and unpredictable performance is a cost you're willing to pay?
> >
> >    I don't write performance-critical applications, but even if I did, why 
> >would
> > I prefer getting the wrong answer faster?
> 
> I agree with Sidhekin and similar mentalities.
> 
> On the range between safety/correctness and speed, a good programming 
> language / 
> tool should always default to the most safe/correct option when the user 
> doesn't 
> specify where on the range they want, and leave it to the power users to 
> explicitly make the trade-off when they know what they're doing.
> 
> In this case, people who explicitly want floats because of performance rather 
> than exact rationals do indeed count as power users.

I'd still pull out the argument that you want the least surprising behavior. Of 
course, I would prefer being able to add two rational numbers with very large 
denominators and have the underlying machinery shorten the result for me, but 
the performance hit is easy to great. Am I missing something here, or wouldn't 
most people expect addition to be a constant time operation?

Imagine a really simple operation: a script that takes a spread sheet, parses 
it and writes out the weighted average of some of the columns. Anyone would 
expect that if 40,000 rows takes 1 second to process, then 80,000 takes 2. With 
Perl 6 not do much. You'd have to switch to "power user mode" to get that kind 
of predictability.

> Normal people are more interested in not being surprised by the answers they 
> get 
> to what should be common-sense questions, such as when adding 10.3 to 14.2.

So far, almost every other language has behaved this way, and it has worked. I 
can see that Rats do solve a problem, but if you'd claim that it is very severe 
then I'd disagree. This is a minor nuisance that I'd only pay a small price to 
fix.

> I should also point out that finance / anything to do with money is an 
> extremely 
> common use case that cares very much about math being exact, its not just 
> esoteric science applications.

I doubt that Rats is a complete solution to the problems you have to solve when 
it come to represent monetary values. My take is you'd need very specific 
rounding algorithms when you convert to a fixed number of digits.

I believe my example with the spread sheet is much more mundane.

> This all being said, I draw the line where implementing is much more 
> complicated 
> to serve esoteric cases.  So for example while exact precision rationals 
> absolutely should be default / part of core, something like symbolic values 
> eg 
> exact representations of irrational numbers, are perfectly valid to, and 
> probably shouldn't, be part of core.  Exact rationals are not particularly 
> complicated.  Its perfectly reasonable to expect in the core that if someone 
> does math that is known to deal with irrationals in general, that loss of 
> precision then is acceptable.

Just to be sure that we are taking about the same thing:

An ideal Rat implementation should be able to always output the least possible 
denominator, right?

And if I happen to add some rational numbers that involve, say, very very large 
prime numbers (intentionally or not), it's clear that the result probably can't 
be shortened much, but the run time of the underlying algorithm may explode.

..and that is acceptable behavior?

..or did I miss something?

M.
-- 
Michael Zedeler
70 25 19 99
mich...@zedeler.dk

dk.linkedin.com/in/mzedeler |twitter.com/mzedeler | github.com/mzedeler

Re: Language design

2015-06-22 Thread Darren Duncan

On 2015-06-16 2:15 PM, The Sidhekin wrote:

On Tue, Jun 16, 2015 at 10:52 PM, Michael Zedeler  wrote:
...and unpredictable performance is a cost you're willing to pay?

   I don't write performance-critical applications, but even if I did, why would
I prefer getting the wrong answer faster?


I agree with Sidhekin and similar mentalities.

On the range between safety/correctness and speed, a good programming language / 
tool should always default to the most safe/correct option when the user doesn't 
specify where on the range they want, and leave it to the power users to 
explicitly make the trade-off when they know what they're doing.


In this case, people who explicitly want floats because of performance rather 
than exact rationals do indeed count as power users.


Normal people are more interested in not being surprised by the answers they get 
to what should be common-sense questions, such as when adding 10.3 to 14.2.


I should also point out that finance / anything to do with money is an extremely 
common use case that cares very much about math being exact, its not just 
esoteric science applications.


This all being said, I draw the line where implementing is much more complicated 
to serve esoteric cases.  So for example while exact precision rationals 
absolutely should be default / part of core, something like symbolic values eg 
exact representations of irrational numbers, are perfectly valid to, and 
probably shouldn't, be part of core.  Exact rationals are not particularly 
complicated.  Its perfectly reasonable to expect in the core that if someone 
does math that is known to deal with irrationals in general, that loss of 
precision then is acceptable.


-- Darren Duncan



Re: Language design

2015-06-20 Thread yary
I like the explanation of how Rats solve a class of rounding errors,
0.3 - (0.2 + 0.1) equals exactly 0 for example. On the other hand,
it's still a compromise that's shifting closer to correctness, fixing
a bunch of potential bugs, but not all in that class:

Rakudo:
> say 2 - (sqrt 2) ** 2
-4.44089209850063e-016

That's OK by me. I can also envision a type  which can perfectly
represent trigonometric and polynomial roots (backed by a symbolic
math package?), that would solve this problem. I can see why that
might be good in the core, for the same reasons that Rats are... or
maybe put them in a module, along with non-integer exponents and trig
functions, so if you can use functions with irrational numbers in
their domain, you also get the numeric types that can perfectly
represent them.

-y


Re: Language design

2015-06-16 Thread The Sidhekin
On Tue, Jun 16, 2015 at 10:52 PM, Michael Zedeler 
wrote:

> ...and unpredictable performance is a cost you're willing to pay?


  I don't write performance-critical applications, but even if I did, why
would I prefer getting the wrong answer faster?


Eirik


Re: Language design

2015-06-16 Thread The Sidhekin
On Tue, Jun 16, 2015 at 10:02 PM, Michael Zedeler 
wrote:

> I'm not saying that there isn't any alternative to the way other languages
> implements floats, but Rats in particular seems to require a
> nondeterministic algorithm in order to be of practical use.
>
  Rats means never having to worry about inaccurate float representations.

$ perl -E '$i+=0.1 for 0..1000; say for $i, $i cmp 100.1' # oops …
100.0999
-1
$ perl6 -e 'my $i; $i+=0.1 for 0..1000; .say for $i, $i cmp 100.1'
100.1
Same
$

  Float inaccuracy is one of the things I'm really looking forward to
forgetting. :)


Eirik


Re: Language design

2015-06-16 Thread Brent Laabs
Yes, unpredictable performance is a price I'm willing to pay.  I'm using a
dynamic language after all.

If you aren't willing to pay it, just use typed variables.  Or even native
types, like num or int.  Choose your own number representation -- there's
more than one way to do it.

The design philosophy in Perl 6 to make common things easy and other things
possible; pathological number sequences are not the common case.

On Tue, Jun 16, 2015 at 1:52 PM, Michael Zedeler  wrote:

> ...and unpredictable performance is a cost you're willing to pay?
>
> M.
>
>
>  The Sidhekin wrote 
>
> On Tue, Jun 16, 2015 at 10:02 PM, Michael Zedeler 
> wrote:
>
>> I'm not saying that there isn't any alternative to the way other
>> languages implements floats, but Rats in particular seems to require a
>> nondeterministic algorithm in order to be of practical use.
>>
>   Rats means never having to worry about inaccurate float representations.
>
> $ perl -E '$i+=0.1 for 0..1000; say for $i, $i cmp 100.1' # oops …
> 100.0999
> -1
> $ perl6 -e 'my $i; $i+=0.1 for 0..1000; .say for $i, $i cmp 100.1'
> 100.1
> Same
> $
>
>   Float inaccuracy is one of the things I'm really looking forward to
> forgetting. :)
>
>
> Eirik
>


Re: Language design

2015-06-16 Thread Michael Zedeler
...and unpredictable performance is a cost you're willing to pay? 

M.

 The Sidhekin wrote 

>On Tue, Jun 16, 2015 at 10:02 PM, Michael Zedeler  wrote:
>
>I'm not saying that there isn't any alternative to the way other languages 
>implements floats, but Rats in particular seems to require a nondeterministic 
>algorithm in order to be of practical use. 
>
>  Rats means never having to worry about inaccurate float representations.
>
>$ perl -E '$i+=0.1 for 0..1000; say for $i, $i cmp 100.1' # oops …
>100.0999
>-1
>$ perl6 -e 'my $i; $i+=0.1 for 0..1000; .say for $i, $i cmp 100.1'
>100.1
>Same
>$
>
>  Float inaccuracy is one of the things I'm really looking forward to 
>forgetting. :)
>
>
>
>Eirik
>


Re: Language design

2015-06-16 Thread Michael Zedeler
I really understand your point. If there was several competing OOP modules, 
things *could* get really complicated (in my opinion, it isn't the case for 
perl 5, but it is worth discussing), but it doesn't seem as if anyone has put 
any effort into defining what needs to be common and what doesn't. 

Seriously, do you believe that the hyperoperators address the problem, you're 
referring to?

Regards, 

Michael. 

 Paweł Murias wrote 

>The goal is to avoid everyone using a different not fully compatible version 
>of everything. Like in perl 5 with the bunch of different ways to do objects, 
>signatures etc. 
>
>Pilling good things on top of each others rather than aiming for an elegant 
>design is what I consider the core idea of Perl.
>
>Being able to add language features removes most benefits of a simple design 
>(easy to create tool support).
>
>
>On 16 June 2015 at 21:08, Fields, Christopher J  wrote:
>
>I like that I can start with a fairly simple subset of Perl 6 but pick up more 
>as I go along, if it’s needed.
>
>
>chris
>
>
>On Jun 16, 2015, at 9:45 AM, Paweł Murias  wrote:
>
>
>I think Perl 6 tries to include too much rather than too little. 
>
>It will be possible to just use a subset 
>
>
>On 16 June 2015 at 10:32, Michael Zedeler  wrote:
>
>On 06/12/15 15:54, Parrot Raiser wrote:
>
>Has somebody been following the discussions on types? http://xkcd.org/1537/ 
>:-)*
>
>Perl6 has something similar to example 9.
>
>Ranges, hyper-operators as well as the "invocation" operators .+ and .* 
>doesn't make any sense to me. Those constructs made me stop using Perl and 
>look elsewhere. It was a hard decision since I've used the language for at 
>least 15 years.
>
>I hope Perl6 regexes will make it far beyond Perl itself and the notion of 
>being able to introduce custom dsl parsed on equal terms as the rest of Perl 6 
>is really sweet.
>
>Regards,
>
>Michael.
>
>-- 
>Michael Zedeler
>70 25 19 99
>mich...@zedeler.dk
>
>dk.linkedin.com/in/mzedeler | twitter.com/mzedeler | github.com/mzedeler
>
>
>
>


Re: Language design

2015-06-16 Thread Michael Zedeler
Yes. It looks nice that Perl 6 recognizes zero in this way, but the consequence 
is that each implementation of Perl 6 has to run a gcd algorithm every now and 
then. 

I'd be very surprised if the computational complexity of any useful (even 
approximate) gcd algorithm doesn't scale with the with the size of the 
denominators, which is why I can't see that it is feasible to use for real 
numerical applications.

I'm not saying that there isn't any alternative to the way other languages 
implements floats, but Rats in particular seems to require a nondeterministic 
algorithm in order to be of practical use. 

Regards, 

Michael. 

 Aristotle Pagaltzis wrote 

>* Michael Zedeler  [2015-06-16 18:55]:
>> For instance, why have Complex and Rat numbers in the core? If you're
>> not working in a very specialized field (which probably *isn't*
>> numerical computation), those datatypes are just esoteric constructs
>> that you'll never use.
>
>https://www.youtube.com/watch?v=S0OGsFmPW2M


Re: Language design

2015-06-16 Thread Paweł Murias
The goal is to avoid everyone using a different not fully compatible
version of everything. Like in perl 5 with the bunch of different ways to
do objects, signatures etc.
Pilling good things on top of each others rather than aiming for an elegant
design is what I consider the core idea of Perl.
Being able to add language features removes most benefits of a simple
design (easy to create tool support).

On 16 June 2015 at 21:08, Fields, Christopher J 
wrote:

>  I like that I can start with a fairly simple subset of Perl 6 but pick
> up more as I go along, if it’s needed.
>
>  chris
>
>  On Jun 16, 2015, at 9:45 AM, Paweł Murias  wrote:
>
>  I think Perl 6 tries to include too much rather than too little.
> It will be possible to just use a subset
>
> On 16 June 2015 at 10:32, Michael Zedeler  wrote:
>
>> On 06/12/15 15:54, Parrot Raiser wrote:
>>
>>> Has somebody been following the discussions on types?
>>> http://xkcd.org/1537/
>>> 
>>> :-)*
>>>
>> Perl6 has something similar to example 9.
>>
>> Ranges, hyper-operators as well as the "invocation" operators .+ and .*
>> doesn't make any sense to me. Those constructs made me stop using Perl and
>> look elsewhere. It was a hard decision since I've used the language for at
>> least 15 years.
>>
>> I hope Perl6 regexes will make it far beyond Perl itself and the notion
>> of being able to introduce custom dsl parsed on equal terms as the rest of
>> Perl 6 is really sweet.
>>
>> Regards,
>>
>> Michael.
>>
>> --
>> Michael Zedeler
>> 70 25 19 99
>> mich...@zedeler.dk
>>
>> dk.linkedin.com/in/mzedeler
>> 
>> | twitter.com/mzedeler
>> 
>> | github.com/mzedeler
>> 
>>
>>
>
>


Re: Language design

2015-06-16 Thread Fields, Christopher J
I like that I can start with a fairly simple subset of Perl 6 but pick up more 
as I go along, if it’s needed.

chris

On Jun 16, 2015, at 9:45 AM, Paweł Murias 
mailto:pawelmur...@gmail.com>> wrote:

I think Perl 6 tries to include too much rather than too little.
It will be possible to just use a subset

On 16 June 2015 at 10:32, Michael Zedeler 
mailto:mich...@zedeler.dk>> wrote:
On 06/12/15 15:54, Parrot Raiser wrote:
Has somebody been following the discussions on types? 
http://xkcd.org/1537/
 :-)*
Perl6 has something similar to example 9.

Ranges, hyper-operators as well as the "invocation" operators .+ and .* doesn't 
make any sense to me. Those constructs made me stop using Perl and look 
elsewhere. It was a hard decision since I've used the language for at least 15 
years.

I hope Perl6 regexes will make it far beyond Perl itself and the notion of 
being able to introduce custom dsl parsed on equal terms as the rest of Perl 6 
is really sweet.

Regards,

Michael.

--
Michael Zedeler
70 25 19 99
mich...@zedeler.dk

dk.linkedin.com/in/mzedeler
 | 
twitter.com/mzedeler
 | 
github.com/mzedeler





Re: Language design

2015-06-16 Thread Aristotle Pagaltzis
* Michael Zedeler  [2015-06-16 18:55]:
> For instance, why have Complex and Rat numbers in the core? If you're
> not working in a very specialized field (which probably *isn't*
> numerical computation), those datatypes are just esoteric constructs
> that you'll never use.

https://www.youtube.com/watch?v=S0OGsFmPW2M


Re: Language design

2015-06-16 Thread Michael Zedeler
This is another of my points: when presented with all the features in Perl 6 - 
what is then essential?

The essential features - besides being presented up front and center to newbies 
- are also good candidates for what should go into the core.

For instance, why have Complex and Rat numbers in the core? If you're not 
working in a very specialized field (which probably *isn't* numerical 
computation), those datatypes are just esoteric constructs that you'll never 
use.

The beauty of Perl 6 is that not only can they be deferred to a module - they 
may still extend the syntax of Perl 6 once they're loaded.

In other words: Perl 6 is perfectly suited to be designed with a tiny core with 
most features in separate modules, and yet it had been provided with the most 
feature rich core (*COUGH* bloated *COUGH*) among most languages I know.

Regards,

Michael.

 Parrot Raiser wrote 

>Subsets will be absolutely essential, if it is to be possible to learn
>it with a reasonable amount of time and effort.
>
>On 6/16/15, Paweł Murias  wrote:
>> I think Perl 6 tries to include too much rather than too little.
>> It will be possible to just use a subset
>>
>> On 16 June 2015 at 10:32, Michael Zedeler  wrote:
>>
>>> On 06/12/15 15:54, Parrot Raiser wrote:
>>>
 Has somebody been following the discussions on types?
 http://xkcd.org/1537/ :-)*

>>> Perl6 has something similar to example 9.
>>>
>>> Ranges, hyper-operators as well as the "invocation" operators .+ and .*
>>> doesn't make any sense to me. Those constructs made me stop using Perl
>>> and
>>> look elsewhere. It was a hard decision since I've used the language for
>>> at
>>> least 15 years.
>>>
>>> I hope Perl6 regexes will make it far beyond Perl itself and the notion
>>> of
>>> being able to introduce custom dsl parsed on equal terms as the rest of
>>> Perl 6 is really sweet.
>>>
>>> Regards,
>>>
>>> Michael.
>>>
>>> --
>>> Michael Zedeler
>>> 70 25 19 99
>>> mich...@zedeler.dk
>>>
>>> dk.linkedin.com/in/mzedeler | twitter.com/mzedeler | github.com/mzedeler
>>>
>>>
>>


Re: Language design

2015-06-16 Thread Parrot Raiser
Subsets will be absolutely essential, if it is to be possible to learn
it with a reasonable amount of time and effort.

On 6/16/15, Paweł Murias  wrote:
> I think Perl 6 tries to include too much rather than too little.
> It will be possible to just use a subset
>
> On 16 June 2015 at 10:32, Michael Zedeler  wrote:
>
>> On 06/12/15 15:54, Parrot Raiser wrote:
>>
>>> Has somebody been following the discussions on types?
>>> http://xkcd.org/1537/ :-)*
>>>
>> Perl6 has something similar to example 9.
>>
>> Ranges, hyper-operators as well as the "invocation" operators .+ and .*
>> doesn't make any sense to me. Those constructs made me stop using Perl
>> and
>> look elsewhere. It was a hard decision since I've used the language for
>> at
>> least 15 years.
>>
>> I hope Perl6 regexes will make it far beyond Perl itself and the notion
>> of
>> being able to introduce custom dsl parsed on equal terms as the rest of
>> Perl 6 is really sweet.
>>
>> Regards,
>>
>> Michael.
>>
>> --
>> Michael Zedeler
>> 70 25 19 99
>> mich...@zedeler.dk
>>
>> dk.linkedin.com/in/mzedeler | twitter.com/mzedeler | github.com/mzedeler
>>
>>
>


Re: Language design

2015-06-16 Thread Paweł Murias
I think Perl 6 tries to include too much rather than too little.
It will be possible to just use a subset

On 16 June 2015 at 10:32, Michael Zedeler  wrote:

> On 06/12/15 15:54, Parrot Raiser wrote:
>
>> Has somebody been following the discussions on types?
>> http://xkcd.org/1537/ :-)*
>>
> Perl6 has something similar to example 9.
>
> Ranges, hyper-operators as well as the "invocation" operators .+ and .*
> doesn't make any sense to me. Those constructs made me stop using Perl and
> look elsewhere. It was a hard decision since I've used the language for at
> least 15 years.
>
> I hope Perl6 regexes will make it far beyond Perl itself and the notion of
> being able to introduce custom dsl parsed on equal terms as the rest of
> Perl 6 is really sweet.
>
> Regards,
>
> Michael.
>
> --
> Michael Zedeler
> 70 25 19 99
> mich...@zedeler.dk
>
> dk.linkedin.com/in/mzedeler | twitter.com/mzedeler | github.com/mzedeler
>
>


Re: Language design

2015-06-16 Thread Michael Zedeler

On 06/12/15 15:54, Parrot Raiser wrote:

Has somebody been following the discussions on types? http://xkcd.org/1537/ :-)*

Perl6 has something similar to example 9.

Ranges, hyper-operators as well as the "invocation" operators .+ and .* 
doesn't make any sense to me. Those constructs made me stop using Perl 
and look elsewhere. It was a hard decision since I've used the language 
for at least 15 years.


I hope Perl6 regexes will make it far beyond Perl itself and the notion 
of being able to introduce custom dsl parsed on equal terms as the rest 
of Perl 6 is really sweet.


Regards,

Michael.

--
Michael Zedeler
70 25 19 99
mich...@zedeler.dk

dk.linkedin.com/in/mzedeler | twitter.com/mzedeler | github.com/mzedeler



Re: Language design

2015-06-12 Thread Bruce Gray

On Jun 12, 2015, at 8:54 AM, Parrot Raiser <1parr...@gmail.com> wrote:

> Has somebody been following the discussions on types? http://xkcd.org/1537/ 
> :-)*

Yes; see the 4 minute lightning talk:
https://www.destroyallsoftware.com/talks/wat
:^)

— 
Bruce Gray (Util of PerlMonks)