!:5 Is NaN.
- Original Message -
From: Roger Hui [EMAIL PROTECTED]
Date: Friday, February 29, 2008 6:26
Subject: Re: [Jbeta] Use of the name 'NaN' deprecated
To: Beta forum beta@jsoftware.com
More precisely, NaN denotes many bit patterns in the IEEE standard.
J displays them all
There are many other values in the IEEE standard which represent invalid
numbers other than NaN. How does 128!:5 treat them? Does it treat them all
as NaN or as numbers?
On Tue, Feb 26, 2008 at 6:37 AM, Raul Miller [EMAIL PROTECTED] wrote:
As near as I can tell, SQL implementations
generally
unhex t
_. _. _. _. _. _. _.
t -: hex unhex t
1
128!:5 unhex t
1 1 1 1 1 1 1
- Original Message -
From: Don Guinn [EMAIL PROTECTED]
Date: Friday, February 29, 2008 4:23
Subject: Re: [Jbeta] Use of the name 'NaN' deprecated
To: Beta forum beta@jsoftware.com
- Original Message -
From: Don Guinn [EMAIL PROTECTED]
Date: Friday, February 29, 2008 4:23
Subject: Re: [Jbeta] Use of the name 'NaN' deprecated
To: Beta forum beta@jsoftware.com
There are many other values in the IEEE standard which represent invalid
numbers other than NaN. How does
]
Date: Monday, February 25, 2008 20:09
Subject: RE: [Jbeta] Use of the name 'NaN' deprecated
To: Beta forum beta@jsoftware.com
Thank you for clarifying the rationale for the
NaN error.
In some languages division by zero is bad and
they throw an error. While in other very well-designed
Nope, just vagaries of benchmarking.
- Original Message -
From: bill lam [EMAIL PROTECTED]
Date: Tuesday, February 26, 2008 2:34
Subject: Re: [Jbeta] Use of the name 'NaN' deprecated
To: Beta forum beta@jsoftware.com
I got these in AMD Athlon
10 (6!:2) 'x*y'
0.030096498
10
on an Intel Celeron (AMD Athlon
does much better).
- Original Message -
From: Oleg Kobchenko [EMAIL PROTECTED]
Date: Monday, February 25, 2008 20:09
Subject: RE: [Jbeta] Use of the name 'NaN' deprecated
To: Beta forum beta@jsoftware.com
Thank you for clarifying the rationale for the
NaN error
that is portable and high
performance handles NaN properly.
- Original Message -
From: Oleg Kobchenko [EMAIL PROTECTED]
To: Beta forum beta@jsoftware.com
Sent: Monday, February 25, 2008 11:09 PM
Subject: RE: [Jbeta] Use of the name 'NaN' deprecated
Thank you for clarifying the rationale
-
From: Roger Hui [EMAIL PROTECTED]
Date: Tuesday, February 26, 2008 0:31
Subject: Re: [Jbeta] Use of the name 'NaN' deprecated
To: Beta forum beta@jsoftware.com
The NaN error will prevent operations to proceed
uninterrupted. Suppose you have a large matrix and complex
geometrical calculations
Yesterday, in response to a system design problem, I brought up the
possibility of using NaN, or one of the other special IEEE values, to flag
a field into which no value had been entered. I was met with stares of
incomprehension, even from an experienced project manager.
This, among other
fool
around with equals.
- Original Message -
From: Oleg Kobchenko [EMAIL PROTECTED]
Date: Monday, February 25, 2008 20:09
Subject: RE: [Jbeta] Use of the name 'NaN' deprecated
To: Beta forum beta@jsoftware.com
Thank you for clarifying the rationale for the
NaN error
1 0 0 0, v=: ?1e5
1 _ 0
0 1 0
0 0 75158
-/ .* M
75158
- Original Message -
From: Roger Hui [EMAIL PROTECTED]
Date: Tuesday, February 26, 2008 0:31
Subject: Re: [Jbeta] Use of the name 'NaN' deprecated
To: Beta forum beta@jsoftware.com
The NaN error
and high
performance handles NaN properly.
- Original Message -
From: Oleg Kobchenko [EMAIL PROTECTED]
To: Beta forum beta@jsoftware.com
Sent: Monday, February 25, 2008 11:09 PM
Subject: RE: [Jbeta] Use of the name 'NaN' deprecated
Thank you for clarifying the rationale
You should read the page for _. in the J6.02 qbeta.
I did so today and finding exactly what I suggested for
the _. entry, I am of course happy with that.
Martin
--
For information
still have some _. left. As I said in my msg,
funny things happen when you fool around with = .
- Original Message -
From: Oleg Kobchenko [EMAIL PROTECTED]
Date: Tuesday, February 26, 2008 9:21
Subject: Re: [Jbeta] Use of the name 'NaN' deprecated
To: Beta forum beta@jsoftware.com
, 2008 10:00
Subject: Re: [Jbeta] Use of the name 'NaN' deprecated
To: Beta forum beta@jsoftware.com
That was my point. I was deliberately using a vague
reference to a complex geometrical calculation to
argue that from computability, decidability or feasibility
viewpoints it's not always practical
When I put try in the beginning of a verb I expect it to catch all errors in
the verb.
It is not picking up the error when a name inn if. is not defined.
If I have undefined name in the verb then tr. catch picks it up but not when
try. catch. is not working when a name is undefined in an if
Of Roger Hui
Sent: Monday, February 25, 2008 1:04 AM
To: Beta forum
Subject: Re: [Jbeta] Use of the name 'NaN' deprecated
Do change 'NaN error' to either 'domain error' (preferred)
or '_. error' .
It is advantageous to have a message for NaN error
distinct from domain error, so that when
for being the first successful
hunter in the treasure hunt.
- Original Message -
From: Henry Rich [EMAIL PROTECTED]
Date: Monday, February 25, 2008 2:34
Subject: RE: [Jbeta] Use of the name 'NaN' deprecated
To: 'Beta forum' beta@jsoftware.com
One can argue that more information is better
forget the distinction
and call them all domain errors.
Henry Rich
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Roger Hui
Sent: Monday, February 25, 2008 11:48 AM
To: Beta forum
Subject: Re: RE: [Jbeta] Use of the name 'NaN' deprecated
1 o. y
a long haul!
- Original Message -
From: Henry Rich [EMAIL PROTECTED]
To: 'Beta forum' beta@jsoftware.com
Sent: Monday, February 25, 2008 5:38 PM
Subject: RE: RE: [Jbeta] Use of the name 'NaN' deprecated
1 o. 1e9 is quite different from 1 o. _ , I think.
If you wanted to, you could
I agree with Henry.
As the Dictionary reads now (and has always read since the 1991
version), the only reference to _. is its Indeterminate entry
itself, namely:
Indeterminate _.
The indeterminate _. results from expressions such as _-_ (infinity
minus infinity) and from expressions (such
The change is much more than substituting NaN for _. or vice versa.
You should read the page for _. in the J6.02 qbeta.
Absolutely no plans to change 0%0 giving 0.
- Original Message -
From: [EMAIL PROTECTED]
Date: Monday, February 25, 2008 16:25
Subject: Re: [Jbeta] Use of the name
.
You should read the page for _. in the J6.02 qbeta.
Absolutely no plans to change 0%0 giving 0.
- Original Message -
From: [EMAIL PROTECTED]
Date: Monday, February 25, 2008 16:25
Subject: Re: [Jbeta] Use of the name 'NaN' deprecated
To: beta@jsoftware.com
I agree with Henry
.
- Original Message -
From: Oleg Kobchenko [EMAIL PROTECTED]
Date: Monday, February 25, 2008 20:09
Subject: RE: [Jbeta] Use of the name 'NaN' deprecated
To: Beta forum beta@jsoftware.com
Thank you for clarifying the rationale for the
NaN error.
In some languages division by zero is bad
Roger and Eric have referred to NaN in their messages. I suggest
that this usage should be avoided.
NaN is meaningful only in reference to the IEEE floating-point
spec.
J is above that. J deals with numbers. Floating-point is an
implementation detail that should not be alluded to in the
take a look at what is in the current beta as that is
what is going to be in the release.
- Original Message -
From: Henry Rich [EMAIL PROTECTED]
To: 'Beta forum' beta@jsoftware.com
Sent: Sunday, February 24, 2008 11:47 AM
Subject: [Jbeta] Use of the name 'NaN' deprecated
Roger
Rich
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric Iverson
Sent: Sunday, February 24, 2008 12:08 PM
To: Beta forum
Subject: Re: [Jbeta] Use of the name 'NaN' deprecated
Your saying _. is indeterminate and has nothing to do with
the IEEE
]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric Iverson
Sent: Sunday, February 24, 2008 12:08 PM
To: Beta forum
Subject: Re: [Jbeta] Use of the name 'NaN' deprecated
Your saying _. is indeterminate and has nothing to do with
the IEEE spec of
Nan doesn't make it so. Our conclusions
of the name 'NaN' deprecated
To: 'Beta forum' beta@jsoftware.com
I think you are replying to a different argument than the
one I was trying to make.
I wasn't suggesting that _. be 'above that' in the sense of
following certain J-defined rules independent of the
IEEE spec. That would be OK
30 matches
Mail list logo
