On Sun, Jul 13, 2008 at 02:17:10PM -0500, Adrian Kreher wrote:
: Hi,
:
: I'm reviewing the tests in S09, and the file
: t/spec/S02-builtin_data_types/multi_dimensional_array.t uses the [0][0]
: indexing format interchangeably with [0;0].
:
: These two formats mean two different things,
On Tue, Jul 15, 2008 at 03:30:24PM +0200, Moritz Lenz wrote:
: Today bacek++ implement complex logarithms in rakudo, and one of the
: tests failed because it assumed the result to be on a different complex
: plane. (log(-1i) returned 0- 1.5708i, while 0 + 3/2*1i was expected).
:
: Should we
On Sun, Jul 13, 2008 at 12:46:30PM +0200, TSa (Thomas Sandlaß) wrote:
: HaloO,
:
: I know that the hot phase of the operator discussions are over.
: But here's a little orthogonalizing idea from my side. The observation
: is that * can be regarded as repeated addition: 5 * 3 == 5 + 5 + 5
: and **
Larry Wall wrote:
On Tue, Jul 15, 2008 at 03:30:24PM +0200, Moritz Lenz wrote:
: Today bacek++ implement complex logarithms in rakudo, and one of the
: tests failed because it assumed the result to be on a different complex
: plane. (log(-1i) returned 0- 1.5708i, while 0 + 3/2*1i was
Jon Lang wrote:
Larry Wall wrote:
On Tue, Jul 15, 2008 at 03:30:24PM +0200, Moritz Lenz wrote:
: Today bacek++ implement complex logarithms in rakudo, and one of the
: tests failed because it assumed the result to be on a different complex
: plane. (log(-1i) returned 0- 1.5708i, while 0 +
Author: larry
Date: Wed Jul 16 12:56:34 2008
New Revision: 14563
Modified:
doc/trunk/design/syn/S04.pod
Log:
[S04] another whack at defining consistent closure semantics
Modified: doc/trunk/design/syn/S04.pod
==
---
Moritz Lenz wrote:
Jon Lang wrote:
By the principle of least surprise, I'd recommend against this. Most
programmers, when they see 'sqrt(1)', will expect a return value of 1,
And that's what they get unless they write it as sqrt(1 + 0i).
I suppose that you _could_ use the programmer's
Jon Lang wrote:
Moritz Lenz wrote:
Jon Lang wrote:
By the principle of least surprise, I'd recommend against this. Most
programmers, when they see 'sqrt(1)', will expect a return value of 1,
And that's what they get unless they write it as sqrt(1 + 0i).
I suppose that you _could_ use the
Let's worry about getting principal values, branch cuts and handling signed
zeros correct before dealing with the interaction of junctions and multi-valued
complex functions.
--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Moritz Lenz wrote:
If the programmer errs on what he thinks is in a variable, it'll always
be a bug.
Yes; but some bugs are easier to make, and harder to catch, than others.
Principle of least surprise:
Suppose sqrt(1) returns any(1, -1):
if sqrt($x) 0.5 { do something }
I can see the
Minor typo:
On 2008 Jul 16, at 15:56, [EMAIL PROTECTED] wrote:
+(again, conceptually at the entry to the outer lexical scope, but
+possible deferred.)
sub foo {
possibly
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator
Author: larry
Date: Wed Jul 16 15:53:34 2008
New Revision: 14564
Modified:
doc/trunk/design/syn/S04.pod
Log:
typo from Brandon++
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod
Mark Biggar wrote:
Let's worry about getting principal values, branch cuts and handling signed
zeros correct before dealing with the interaction of junctions and
multi-valued complex functions.
Indeed.
BTW, two good references on this that we might want to plagiarizer.I mean
borrow
On 2008 Jul 16, at 18:48, Jon Lang wrote:
Moritz Lenz wrote:
Principle of least surprise:
Suppose sqrt(1) returns any(1, -1):
if sqrt($x) 0.5 { do something }
I can see the big, fat WTF written in the face of programmer who
tries
to debug that code, and doesn't know about junctions. It
14 matches
Mail list logo
