I don't really care about this edge case, interesting as it is. I have
had the need to estimate large combinations in networks but used
Stirling's approximation.
On 02/03/2016 09:20 PM, programming-requ...@forums.jsoftware.com wrote:
Message: 4
Date: Wed, 3 Feb 2016 19:30:22 -0500
From: Raul
Seeing as J currently only has 32-bit and 64-bit implementations, I
would be inclined to go with
MAXINT =: ->: MININT =: _2 <.@^ <: +:^:IF64 32
The auto-detection is cool though; you can tighten it up a bit by
working with negative numbers again.
MAXINT =: ->: MININT =: <.-: +:^:(4>:3!:0)^:_ ]_1
On Wed, Feb 3, 2016 at 5:19 PM, Marshall Lochbaum wrote:
> I sent an email about the problem of coercion to integer a month ago; my
> recommendation was fl:
>
> MAX =: ->: MIN =: _2 <.@^ 63
> fl =: ((MAX*-.@]) + [: <. MIN>.*) <:&MAX
Note that this won't work right on 32 bit J. The values for MAX
I certainly agree that Dan's requested feature shouldn't be J's default
behavior. The result of an arithmetic operation should follow from the
behavior of the relevant datatype (here, IEEE float) and the type
conversion rules.
I sent an email about the problem of coercion to integer a month ago; m
I see, you were referring to the "no notion of infinity" statement, not
the statement about conversion. You are correct extended and rational
have special values to represent infinity but they are different from
the floating point standard so you can't just do "a < b" in C for a
rational a and
1r2+x:_
_
1r2<.x:_
1r2
I do not see what "no arithmetic being done in an example" has to do
with the implementation of rational infinity.
--
Raul
On Wed, Feb 3, 2016 at 4:16 PM, Thomas Costigliola wrote:
> There is no arithmetic being done.
>
> On 02/03/2016 04:06 PM, Raul Miller wrote:
There is no arithmetic being done.
On 02/03/2016 04:06 PM, Raul Miller wrote:
If that's the case, how does this happen?
3!:0 x:_
128
--
For information about J forums see http://www.jsoftware.com/forums.htm
If that's the case, how does this happen?
3!:0 x:_
128
--
Raul
On Wed, Feb 3, 2016 at 4:04 PM, Thomas Costigliola wrote:
> Infinity is a feature of double; extended integers and rationals have no
> notion of infinity so normally arithmetic gets done in double. So if your
> array has number
Infinity is a feature of double; extended integers and rationals have no
notion of infinity so normally arithmetic gets done in double. So if
your array has numbers that are too large for machine integers the easy
way out is to convert the extended precision. You could test for special
cases, e
I guess I do not know which issue you are struggling with.
Can you be more specific?
Thanks,
--
Raul
On Wed, Feb 3, 2016 at 3:47 PM, 'Pascal Jasmin' via Programming
wrote:
> in this case, the issue has to do with _ and __ not having equivalents in
> extended numbers, and I'm unsure its poss
in this case, the issue has to do with _ and __ not having equivalents in
extended numbers, and I'm unsure its possible to create one. MAXINT doesn't
help if we don't want to conver 1000 bit numbers to 64 bits.
So, the override to make is to test for one argument being _ or __ . That is
proba
Actually, I don't care about coercing floating point to integer - just
boolean to integer. And, this is just a model. So:
MAXINT=: +/1,(#~1-2&|)".":x:+:^:(4>:3!:0)^:a:1
MININT=: _1-MAXINT
setype=:dyad define
select. x
case. 1 do. 0~:y
case. 4 do. <.MININT>.y<.MAXINT
case. 8 do. y<._
I think, in this case, that we are working against the language
definition. That tends to introduce quirks and other problems into the
language.
Specifically, I think we would be working against
http://www.jsoftware.com/help/dictionary/dictg.htm and the table
introduced by the phrase "Dyadic verbs
I know we have yet to organize a formal process for building and disseminating
a community-driven implementation of J, but in anticipation of that day’s
arrival, perhaps we can start collecting community-driven proposals for
enhancements?
One such enhancement could be special code that detects
14 matches
Mail list logo
