Hi Hans-Peter,
thanks, that explains it. Interesting side-effect of ⎕FC.
Hopefully fixed in *SVN 1735*.
If you have broken workspaces created with this
bug then maybe the following can fix them:
*)CLEAR**
**∇Z←A E B**
** Z←A×10⋆B**
**∇**
**)COPY broken_WS**
**)DUMP broken_WS**
*
Best Regards,
Jürgen
On 9/30/23 15:54, Hans-Peter Sorge wrote:
Hi Jürgen,
.. not every key-stroke.
But this one:
⎕FC←'.,⋆0_*-*'
)WSID E_13
WAS CLEAR WS
)DUMP
⎕CT ← 1E-13
The Corona case: ⎕FC←(,⎕UCS 46 44 8902),'0_-' is set to "-" and all
negative numbers get infected ...
Best Regards
Hans-Peter
Am 30.09.23 um 00:07 schrieb Hans-Peter Sorge:
Hi Jürgen,
*LOL with greetings from Corona :-))*
1. Yes, there is a WS having E-13 (dated 2020-11-24 )
2. It is a Corona WS
3. I did some statistical analysis on Corona data Biontech vs placebo
4. basically: calc, file the result, )dump
5. File content (written with ⎕FIO[56]) records are like
1.365813058E-7 1.365813058E-7
6. WS )dumped has a var content like '-19.5 0J-1.573922168E41
0J-1.573922168E41'
That there is an imaginary part is new to me....
7. )loading fails with
DUMPED 2020-11-24 16:45:00 (GMT+2)
VALUE ERROR+
geimpft_normal[⍳1]←9.637493724E24 J-1.573922168E41
^
As it turns out, all negativ numbers are "-" instead of "¯"
What ever the cause was three years ago - I do not remember all key
strokes from that time.
And no - that is not Corona.
How the E-13 got into a *newly* created WS (one week old) is out of
my scope.
And the )load only failed because i have a function E on board.
Within my apl / xml inventory there is no E¯13 / e-13 mix.
Best Regards
Hans-Peter
Am 29.09.23 um 16:33 schrieb Dr. Jürgen Sauermann:
Hi Peter,
it very much looks like the VALENCE ERROR is caused by the minus
sign in 1E-13. The question is where the minus comes from. There
are two possibilities:
1. The most likely case is that the user has written 1E-13 in some
APL script (but meant to write 1E¯13). In this case GNU APL seems to
behave correctly (1E-13 is parsed 1 E - 13 and then E must be
dyadic).
2. The minus comes from am earlier )DUMP which wrote 1E-13 instead of
1E¯13. In that case the information below is not sufficient as to
how the
fault was produced.
Please check your workspaces with a text editor (both .xml and .apl
files
are human readable). GNU APL tends to use uppercase E and ¯ (like
1E¯13)
in .apl files and lowercase e and ASCII - (like 1e-13) in .xml
files. Therefore
the combination of uppercase E and ASCII - is not supposed to occur in
either file format.
Best Regards,
Jürgen
On 9/29/23 14:28, Hans-Peter Sorge wrote:
Hi,
I have a function E (as simple as in test below) in my workspace
(WS size 2.9MB).
)DUMP and
)loading it produces an error:
)LOAD ........
DUMPED 2023-09-28 19:44:54 (GMT+2)
VALENCE ERROR
⎕CT←1 E-13
^ ^
Just
)ERASE E
∇E .... ∇ ⍝ recreate ist
)DUMP
)LOAD ...
fixed if
Best Regards
Hans-Peter
