gnudatalanguage
plot hangs when ploting array with almost equal numbers
The plot of this array hangs infinite
bash$ gdl
GDL - GNU Data Language, Version v1.0.6-25-g67b3abca
- For basic information type HELP,/INFO
- Default library routine search path used (GDL_PATH/IDL_PATH env. var. not set): /usr/local/bin/../share/gnudatalanguage/lib
- Using WxWidgets as graphics library (windows and widgets).
- Using local drivers in /usr/local/bin/../share/gnudatalanguage/drivers
- Please report bugs, feature or help requests and patches at: https://github.com/gnudatalanguage/gdl
% Compiled module: SETUP_KEYS.
GDL> d=[1d0, 1d0, 1d0, 0.99999999999999988897769754d0]
GDL> plot,d
Plots fine here (Version v1.0.6-27-gdb9f3ba6-dirty, macOS 14.7, M2):
GDL> d=[1d0, 1d0, 1d0, 0.99999999999999988897769754d0] GDL> plot,d, psym=6 GDL> help, d D DOUBLE = Array[4] GDL> PM, d 1.0000000 1.0000000 1.0000000 1.00000000 GDL>
Odd (maybe) that the last element has 8 zeros? Same in IDL gives 7 for all four (1.0000000).
For me, it works as presented, but hangs if I try:
plot,d, ys=16
I do also see the extra zero on the last element when printing.
works4me: GDL, last version:
GDL> plot,d, psym=16
% PLOT: PSYM (plotting symbol) out of range.
% Execution halted at: $MAIN$
@brandy125 please note that since #1886 GDL is no more dependent on plplot library (so, your version showing "Using local drivers in /usr/local/bin/../share/gnudatalanguage/drivers" is older than #1886) .... and #1886 fulfills your request #1619 for more than 100 windows... :smile:
works4me: GDL, last version:
GDL> plot,d, psym=16 % PLOT: PSYM (plotting symbol) out of range. % Execution halted at: $MAIN$
Sorry, finger trouble. I meant:
plot, d, ystyle=16
works4me: GDL, last version:
GDL> plot,d, psym=16 % PLOT: PSYM (plotting symbol) out of range. % Execution halted at: $MAIN$Sorry, finger trouble. I meant:
plot, d, ystyle=16
yes, GDL is hanged.
for the record, plplot uses an infinite loop to write ticks (?!!), but the increment (2E-17!) was too small to change the base value of 0.99999999999999988897769754d0 (see C++ 'epsilon()' discussion). If d had been 'around' a greater value (say, d+=10) the problem would no have appeared. another example:
GDL> print, 1d,d[3],1d + d[3],format='(F32.26)'
1.00000000000000000000000000
0.99999999999999988897769754
2.00000000000000000000000000 ; not 1.99999999999999988897769754