Special code is not the problem, it's the solution. The system is doing
what you ask of it.
15(^)22 5 3 20 15 18
7.48183e25 759375 3375 3.32526e23 4.37894e17 1.47789e21
^ produces floating-point results. If they require more than 53 bits of
significance you will lose low-order bits and the
I should have phrased my question as, Has anyone used negative level
besides _1?
L:_1 always means 'open one boxing level' in either definition and
differs from &.> only in that an open argument is passed unchanged to
the opened boxes of the other. To get that effect with the new
definition
Yes, I am aware of incompatibilities. :)
> Could you replace the level with a positive constant or a negative
constant under the new definition?
I suspect that the easiest way to faithfully emulate the current adverb
L:_1, or more generally L: r (for negative value r) would be based on its
curre
I don't know what the context is of the numbers used in the fsoj example,
but wouldn't the loss of precision be clearer if you used a simple,
ascending sequence on the right?
29|15^10+i.12
13 21 0 0 0 0 0 0 0 0 0 0
29|15^ x: 10+i.12
13 21 25 27 28 14 7 18 9 19 24 12
15(29&|@^)10+i.12
13 21
So, Henry (et al), I think you're suggesting an explanation like the
following to replace the existing explanation which I include further
below. Yes?
**proposed rewrite below ***
Although the example below does not suggest a problem because the numbers
are relatively moderate here, terms
I would not say 'capacity', or 'computer'. The problem is the precision
of floating-point numbers. Floating-point can store numbers that big,
but not exactly. If you did the computation with extended integers, you
could also get an exact answer, but much more slowly without the special
code.
Henry, the sentence with the words 'capacity' and 'computer' is in the
original text.
So, could you suggest an alternative phrasing?
On Sun, Jul 29, 2018 at 2:16 PM, Henry Rich wrote:
> I would not say 'capacity', or 'computer'. The problem is the precision
> of floating-point numbers. Floatin
cs=.29
cs | 15 ^ 22 5 3 20 15 18
0 10 11 0 0 0
The zeros in the above indicate that there is a problem, namely that
numbers such as 15^22 are very large and are approximated when represented as
floating-point values. The residue of the approximate value is not useful.
This is easily solved
< L:_2 in the new definition operates two levels down, akin to &.>&.> .
I guess L:_1 would be equivalent to &.>. However, L:_2 would be only
similar to &.>&.> because, for example,
$&.>&.> t
┌──┬───┐
│┌┐│┌─┬─┬─┐│
│3│2│2││
│└┘│└─┴─┴─┘│
└──┴───┘
does not agree with the result of $
The proposal for L:_2 leaves boxes that are less than 2 levels down
unchanged. $&.>&.> applies $ somewhere in every branch. That's why I
said 'akin to' rather than 'equivalent to'.
The Dictionary gives a formal definition of negative rank. That's not a
description. When the tree has irregu
From your wiki entry, this is the current behaviout:
$L:_3 t
┌─┬─┐
│1│┌───┬─┬─┐│
│ ││┌─┬─┬─┐│2│2││
│ │││3│1│2││ │ ││
│ ││└─┴─┴─┘│ │ ││
│ │└───┴─┴─┘│
└─┴─┘
which is quite reasonable: " if there is an appropriate "-3" level then apply
there, else apply at m
" if there is an appropriate "-3" level then apply there, else apply at maximum
depth."
As a rule describing current behavior, this is wrong. It suffers from a
couple of undefined terms: (1) what is -3 level? (2) what is maximum depth?
If -3 level means "3 levels down from the top" (or equiv
so L:_2 would be "one level down from top level". Its not quite the same as
"double each"
$&.>&.> t
┌──┬───┐
│┌┐│┌─┬─┬─┐│
│3│2│2││
│└┘│└─┴─┴─┘│
└──┴───┘
I would verbalize that as "at -2 levels or operate on null"
regarding: " if there is an appropriate "-2" level then apply
> It would be enlightening to all of us (or just me) if someone could point
out an exception to the heuristic, or provide a more accurate one.
Consider the following right argument,
Y=. 5!:2@:<'toJ'
the next sentence just echoes the arguments taken by the verb ([echo) and
reproduces Y,
(
14 matches
Mail list logo
