1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574 2575 2576 2577 2578 2579 2580 2581 2582 2583 2584 2585 2586 2587 2588 2589 2590 2591 2592 2593 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 2622 2623 2624 2625 2626 2627 2628 2629 2630 2631 2632 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 2678 2679 2680 2681 2682 2683 2684 2685 2686 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 2697 2698 2699 2700 2701 2702 2703 2704 2705 2706 2707 2708 2709 2710 2711 2712 2713 2714 2715 2716 2717 2718 2719 2720 2721 2722 2723 2724 2725 2726 2727 2728 2729 2730 2731 2732 2733 2734 2735 2736 2737 2738 2739 2740 2741 2742 2743 2744 2745 2746 2747 2748 2749 2750 2751 2752 2753 2754 2755 2756 2757 2758 2759 2760 2761 2762 2763 2764 2765 2766 2767 2768 2769 2770 2771 2772 2773 2774 2775 2776 2777 2778 2779 2780 2781 2782 2783 2784 2785 2786 2787 2788 2789 2790 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 2801 2802 2803 2804 2805 2806 2807 2808 2809 2810 2811 2812 2813 2814 2815 2816 2817 2818 2819 2820 2821 2822 2823 2824 2825 2826 2827 2828 2829 2830 2831 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 2849 2850 2851 2852 2853 2854 2855 2856 2857 2858 2859 2860 2861 2862 2863 2864 2865 2866 2867 2868 2869 2870 2871 2872 2873 2874 2875 2876 2877 2878 2879 2880 2881 2882 2883 2884 2885 2886 2887 2888 2889 2890 2891 2892 2893 2894 2895 2896 2897 2898 2899 2900 2901 2902 2903 2904 2905 2906 2907 2908 2909 2910 2911 2912 2913 2914 2915 2916 2917 2918 2919 2920 2921 2922 2923 2924 2925 2926 2927 2928 2929 2930 2931 2932 2933 2934 2935 2936 2937 2938 2939 2940 2941 2942 2943 2944 2945 2946 2947 2948 2949 2950 2951 2952 2953 2954 2955 2956 2957 2958 2959 2960 2961 2962 2963 2964 2965 2966 2967 2968 2969 2970 2971 2972 2973 2974 2975 2976 2977 2978 2979 2980 2981 2982 2983 2984 2985 2986 2987 2988 2989 2990 2991 2992 2993 2994 2995 2996 2997 2998 2999 3000 3001 3002 3003 3004 3005 3006 3007 3008 3009 3010 3011 3012 3013 3014 3015 3016 3017 3018 3019 3020 3021 3022 3023 3024 3025 3026 3027 3028 3029 3030 3031 3032 3033 3034 3035 3036 3037 3038 3039 3040 3041 3042 3043 3044 3045 3046 3047 3048 3049 3050 3051 3052 3053 3054 3055 3056 3057 3058 3059 3060 3061 3062 3063 3064 3065 3066 3067 3068 3069 3070 3071 3072 3073 3074 3075 3076 3077 3078 3079 3080 3081 3082 3083 3084 3085 3086 3087 3088 3089 3090 3091 3092 3093 3094 3095 3096 3097 3098 3099 3100 3101 3102 3103 3104 3105 3106 3107 3108 3109 3110 3111 3112 3113 3114 3115 3116 3117 3118 3119 3120 3121 3122 3123 3124 3125 3126 3127 3128 3129 3130 3131 3132 3133 3134 3135 3136 3137 3138 3139 3140 3141 3142 3143 3144 3145 3146 3147 3148 3149 3150 3151 3152 3153 3154 3155 3156 3157 3158 3159 3160 3161 3162 3163 3164 3165 3166 3167 3168 3169 3170 3171 3172 3173 3174 3175 3176 3177 3178 3179 3180 3181 3182 3183 3184 3185 3186 3187 3188 3189 3190 3191 3192 3193 3194 3195 3196 3197 3198 3199 3200 3201 3202 3203 3204 3205 3206 3207 3208 3209 3210 3211 3212 3213 3214 3215 3216 3217 3218 3219 3220 3221 3222 3223 3224 3225 3226 3227 3228 3229 3230 3231 3232 3233 3234 3235 3236 3237 3238 3239 3240 3241 3242 3243 3244 3245 3246 3247 3248 3249 3250 3251 3252 3253 3254 3255 3256 3257 3258 3259 3260 3261 3262 3263 3264 3265 3266 3267 3268 3269 3270 3271 3272 3273 3274 3275 3276 3277 3278 3279 3280 3281 3282 3283 3284 3285 3286 3287 3288 3289 3290 3291 3292 3293 3294 3295 3296 3297 3298 3299 3300 3301 3302 3303 3304 3305 3306 3307 3308 3309 3310 3311 3312 3313 3314 3315 3316 3317 3318 3319 3320 3321 3322 3323 3324 3325 3326 3327 3328 3329 3330 3331 3332 3333 3334 3335 3336 3337 3338 3339 3340 3341 3342 3343 3344 3345 3346 3347 3348 3349 3350 3351 3352 3353 3354 3355 3356 3357 3358 3359 3360 3361 3362 3363 3364 3365 3366 3367 3368 3369 3370 3371 3372 3373 3374 3375 3376 3377 3378 3379 3380 3381 3382 3383 3384 3385 3386 3387 3388 3389 3390 3391 3392 3393 3394 3395 3396 3397 3398 3399 3400 3401 3402 3403 3404 3405 3406 3407 3408 3409 3410 3411 3412 3413 3414 3415 3416 3417 3418 3419 3420 3421 3422 3423 3424 3425 3426 3427 3428 3429 3430 3431 3432 3433 3434 3435 3436 3437 3438 3439 3440 3441 3442 3443 3444 3445 3446 3447 3448 3449 3450 3451 3452 3453 3454 3455 3456 3457 3458 3459 3460 3461 3462 3463 3464 3465 3466 3467 3468 3469 3470 3471 3472 3473 3474 3475 3476 3477 3478 3479 3480 3481 3482 3483 3484 3485 3486 3487 3488 3489 3490 3491 3492 3493 3494 3495 3496 3497 3498 3499 3500 3501 3502 3503 3504 3505 3506 3507 3508 3509 3510 3511 3512 3513 3514 3515 3516 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3530 3531 3532 3533 3534 3535 3536 3537 3538 3539 3540 3541 3542 3543 3544 3545 3546 3547 3548 3549 3550 3551 3552 3553 3554 3555 3556 3557 3558 3559 3560 3561 3562 3563 3564 3565 3566 3567 3568 3569 3570 3571 3572 3573 3574 3575 3576 3577 3578 3579 3580 3581 3582 3583 3584 3585 3586 3587 3588 3589 3590 3591 3592 3593 3594 3595 3596 3597 3598 3599 3600 3601 3602 3603 3604 3605 3606 3607 3608 3609 3610 3611 3612 3613 3614 3615 3616 3617 3618 3619 3620 3621 3622 3623 3624 3625 3626 3627 3628 3629 3630 3631 3632 3633 3634 3635 3636 3637 3638 3639 3640 3641 3642 3643 3644 3645 3646 3647 3648 3649 3650 3651 3652 3653 3654 3655 3656 3657 3658 3659 3660 3661 3662 3663 3664 3665 3666 3667 3668 3669 3670 3671 3672 3673 3674 3675 3676 3677 3678 3679 3680 3681 3682 3683 3684 3685 3686 3687 3688 3689 3690 3691 3692 3693 3694 3695 3696 3697 3698 3699 3700 3701 3702 3703 3704 3705 3706 3707 3708 3709 3710 3711 3712 3713 3714 3715 3716 3717 3718 3719 3720 3721 3722 3723 3724 3725 3726 3727 3728 3729 3730 3731 3732 3733 3734 3735 3736 3737 3738 3739 3740 3741 3742 3743 3744 3745 3746 3747 3748 3749 3750 3751 3752 3753 3754 3755 3756 3757 3758 3759 3760 3761 3762 3763 3764 3765 3766 3767 3768 3769 3770 3771 3772 3773 3774 3775 3776 3777 3778 3779 3780 3781 3782 3783 3784 3785 3786 3787 3788 3789 3790 3791 3792 3793 3794 3795 3796 3797 3798 3799 3800 3801 3802 3803 3804 3805 3806 3807 3808 3809 3810 3811 3812 3813 3814 3815 3816 3817 3818 3819 3820 3821 3822 3823 3824 3825 3826 3827 3828 3829 3830 3831 3832 3833 3834 3835 3836 3837 3838 3839 3840 3841 3842 3843 3844 3845 3846 3847 3848 3849 3850 3851 3852 3853 3854 3855 3856 3857 3858 3859 3860 3861 3862 3863 3864 3865 3866 3867 3868 3869 3870 3871 3872 3873 3874 3875 3876 3877 3878 3879 3880 3881 3882 3883 3884 3885 3886 3887 3888 3889 3890 3891 3892 3893 3894 3895 3896 3897 3898 3899 3900 3901 3902 3903 3904 3905 3906 3907 3908 3909 3910 3911 3912 3913 3914 3915 3916 3917 3918 3919 3920 3921 3922 3923 3924 3925 3926 3927 3928 3929 3930 3931 3932 3933 3934 3935 3936 3937 3938 3939 3940 3941 3942 3943 3944 3945 3946 3947 3948 3949 3950 3951 3952 3953 3954 3955 3956 3957 3958 3959 3960 3961 3962 3963 3964 3965 3966 3967 3968 3969 3970 3971 3972 3973 3974 3975 3976 3977 3978 3979 3980 3981 3982 3983 3984 3985 3986 3987 3988 3989 3990 3991 3992 3993 3994 3995 3996 3997 3998 3999 4000 4001 4002 4003 4004 4005 4006 4007 4008 4009 4010 4011 4012 4013 4014 4015 4016 4017 4018 4019 4020 4021 4022 4023 4024 4025 4026 4027 4028 4029 4030 4031 4032 4033 4034 4035 4036 4037 4038 4039 4040 4041 4042 4043 4044 4045 4046 4047 4048 4049 4050 4051 4052 4053 4054 4055 4056 4057 4058 4059 4060 4061 4062 4063 4064 4065 4066 4067 4068 4069 4070 4071 4072 4073 4074 4075 4076 4077 4078 4079 4080 4081 4082 4083 4084 4085 4086 4087 4088 4089 4090 4091 4092 4093 4094 4095 4096 4097 4098 4099 4100 4101 4102 4103 4104 4105 4106 4107 4108 4109 4110 4111 4112 4113 4114 4115 4116 4117 4118 4119 4120 4121 4122 4123 4124 4125 4126 4127 4128 4129 4130 4131 4132 4133 4134 4135 4136 4137 4138 4139 4140 4141 4142 4143 4144 4145 4146 4147 4148 4149 4150 4151 4152 4153 4154 4155 4156 4157 4158 4159 4160 4161 4162 4163 4164 4165 4166 4167 4168 4169 4170 4171 4172 4173 4174 4175 4176 4177 4178 4179 4180 4181 4182 4183 4184 4185 4186 4187 4188 4189 4190 4191 4192 4193 4194 4195 4196 4197 4198 4199 4200 4201 4202 4203 4204 4205 4206 4207 4208 4209 4210 4211 4212 4213 4214 4215 4216 4217 4218 4219 4220 4221 4222 4223 4224 4225 4226 4227 4228 4229 4230 4231 4232 4233 4234 4235 4236 4237 4238 4239 4240 4241 4242 4243 4244 4245 4246 4247 4248 4249 4250 4251 4252 4253 4254 4255 4256 4257 4258 4259 4260 4261 4262 4263 4264 4265 4266 4267 4268 4269 4270 4271 4272 4273 4274 4275 4276 4277 4278 4279 4280 4281 4282 4283 4284 4285 4286 4287 4288 4289 4290 4291 4292 4293 4294 4295 4296 4297 4298 4299 4300 4301 4302 4303 4304 4305 4306 4307 4308 4309 4310 4311 4312 4313 4314 4315 4316 4317 4318 4319 4320 4321 4322 4323 4324 4325 4326 4327 4328 4329 4330 4331 4332 4333 4334 4335 4336 4337 4338 4339 4340 4341 4342 4343 4344 4345 4346 4347 4348 4349 4350 4351 4352 4353 4354 4355 4356 4357 4358 4359 4360 4361 4362 4363 4364 4365 4366 4367 4368 4369 4370 4371 4372 4373 4374 4375 4376 4377 4378 4379 4380 4381 4382 4383 4384 4385 4386 4387 4388 4389 4390 4391 4392 4393 4394 4395 4396 4397 4398 4399 4400 4401 4402 4403 4404 4405 4406 4407 4408 4409 4410 4411 4412 4413 4414 4415 4416 4417 4418 4419 4420 4421 4422 4423 4424 4425 4426 4427 4428 4429 4430 4431 4432 4433 4434 4435 4436 4437 4438 4439 4440 4441 4442 4443 4444 4445 4446 4447 4448 4449 4450 4451 4452 4453 4454 4455 4456 4457 4458 4459 4460 4461 4462 4463 4464 4465 4466 4467 4468 4469 4470 4471 4472 4473 4474 4475 4476 4477 4478 4479 4480 4481 4482 4483 4484 4485 4486 4487 4488 4489 4490 4491 4492 4493 4494 4495 4496 4497 4498 4499 4500 4501 4502 4503 4504 4505 4506 4507 4508 4509 4510 4511 4512 4513 4514 4515 4516 4517 4518 4519 4520 4521 4522 4523 4524 4525 4526 4527 4528 4529 4530 4531 4532 4533 4534 4535 4536 4537 4538 4539 4540 4541 4542 4543 4544 4545 4546 4547 4548 4549 4550 4551 4552 4553 4554 4555 4556 4557 4558 4559 4560 4561 4562 4563 4564 4565 4566 4567 4568 4569 4570 4571 4572 4573 4574 4575 4576 4577 4578 4579 4580 4581 4582 4583 4584 4585 4586 4587 4588 4589 4590 4591 4592 4593 4594 4595 4596 4597 4598 4599 4600 4601 4602 4603 4604 4605 4606 4607 4608 4609 4610 4611 4612 4613 4614 4615 4616 4617 4618 4619 4620 4621 4622 4623 4624 4625 4626 4627 4628 4629 4630 4631 4632 4633 4634 4635 4636 4637 4638 4639 4640 4641 4642 4643 4644 4645 4646 4647 4648 4649 4650 4651 4652 4653 4654 4655 4656 4657 4658 4659 4660 4661 4662 4663 4664 4665 4666 4667 4668 4669 4670 4671 4672 4673 4674 4675 4676 4677 4678 4679 4680 4681 4682 4683 4684 4685 4686 4687 4688 4689 4690 4691 4692 4693 4694 4695 4696 4697 4698 4699 4700 4701 4702 4703 4704 4705 4706 4707 4708 4709 4710 4711 4712 4713 4714 4715 4716 4717 4718 4719 4720 4721 4722 4723 4724 4725 4726 4727 4728 4729 4730 4731 4732 4733 4734 4735 4736 4737 4738 4739 4740 4741 4742 4743 4744 4745 4746 4747 4748 4749 4750 4751 4752 4753 4754 4755 4756 4757 4758 4759 4760 4761 4762 4763 4764 4765 4766 4767 4768 4769 4770 4771 4772 4773 4774 4775 4776 4777 4778 4779 4780 4781 4782 4783 4784 4785 4786 4787 4788 4789 4790 4791 4792 4793 4794 4795 4796 4797 4798 4799 4800 4801 4802 4803 4804 4805 4806 4807 4808 4809 4810 4811 4812 4813 4814 4815 4816 4817 4818 4819 4820 4821 4822 4823 4824 4825 4826 4827 4828 4829 4830 4831 4832 4833 4834 4835 4836 4837 4838 4839 4840 4841 4842 4843 4844 4845 4846 4847 4848 4849 4850 4851 4852 4853 4854 4855 4856 4857 4858 4859 4860 4861 4862 4863 4864 4865 4866 4867 4868 4869 4870 4871 4872 4873 4874 4875 4876 4877 4878 4879 4880 4881 4882 4883 4884 4885 4886 4887 4888 4889 4890 4891 4892 4893 4894 4895 4896 4897 4898 4899 4900 4901 4902 4903 4904 4905 4906 4907 4908 4909 4910 4911 4912 4913 4914 4915 4916 4917 4918 4919 4920 4921 4922 4923 4924 4925 4926 4927 4928 4929 4930 4931 4932 4933 4934 4935 4936 4937 4938 4939 4940 4941 4942 4943 4944 4945 4946 4947 4948 4949 4950 4951 4952 4953 4954 4955 4956 4957 4958 4959 4960 4961 4962 4963 4964 4965 4966 4967 4968 4969 4970 4971 4972 4973 4974 4975 4976 4977 4978 4979 4980 4981 4982 4983 4984 4985 4986 4987 4988 4989 4990 4991 4992 4993 4994 4995 4996 4997 4998 4999 5000 5001 5002 5003 5004 5005 5006 5007 5008 5009 5010 5011 5012 5013 5014 5015 5016 5017 5018 5019 5020 5021 5022 5023 5024 5025 5026 5027 5028 5029 5030 5031 5032 5033 5034 5035 5036 5037 5038 5039 5040 5041 5042 5043 5044 5045 5046 5047 5048 5049 5050 5051 5052 5053 5054 5055 5056 5057 5058 5059 5060 5061 5062 5063 5064 5065 5066 5067 5068 5069 5070 5071 5072 5073 5074 5075 5076 5077 5078 5079 5080 5081 5082 5083 5084 5085 5086 5087 5088 5089 5090 5091 5092 5093 5094 5095 5096 5097 5098 5099 5100 5101 5102 5103 5104 5105 5106 5107 5108 5109 5110 5111 5112 5113 5114 5115 5116 5117 5118 5119 5120 5121 5122 5123 5124 5125 5126 5127 5128 5129 5130 5131 5132 5133 5134 5135 5136 5137 5138 5139 5140 5141 5142 5143 5144 5145 5146 5147 5148 5149 5150 5151 5152 5153 5154 5155 5156 5157 5158 5159 5160 5161 5162 5163 5164 5165 5166 5167 5168 5169 5170 5171 5172 5173 5174 5175 5176 5177 5178 5179 5180 5181 5182 5183 5184 5185 5186 5187 5188 5189 5190 5191 5192 5193 5194 5195 5196 5197 5198 5199 5200 5201 5202 5203 5204 5205 5206 5207 5208 5209 5210 5211 5212 5213 5214 5215 5216 5217 5218 5219 5220 5221 5222 5223 5224 5225 5226 5227 5228 5229 5230 5231 5232 5233 5234 5235 5236 5237 5238 5239 5240 5241 5242 5243 5244 5245 5246 5247 5248 5249 5250 5251 5252 5253 5254 5255 5256 5257 5258 5259 5260 5261 5262 5263 5264 5265 5266 5267 5268 5269 5270 5271 5272 5273 5274 5275 5276 5277 5278 5279 5280 5281 5282 5283 5284 5285 5286 5287 5288 5289 5290 5291 5292 5293 5294 5295 5296 5297 5298 5299 5300 5301 5302 5303 5304 5305 5306 5307 5308 5309 5310 5311 5312 5313 5314 5315 5316 5317 5318 5319 5320 5321 5322 5323 5324 5325 5326 5327 5328 5329 5330 5331 5332 5333 5334 5335 5336 5337 5338 5339 5340 5341 5342 5343 5344 5345 5346 5347 5348 5349 5350 5351 5352 5353 5354 5355 5356 5357 5358 5359 5360 5361 5362 5363 5364 5365 5366 5367 5368 5369 5370 5371 5372 5373 5374 5375 5376 5377 5378 5379 5380 5381 5382 5383 5384 5385 5386 5387 5388 5389 5390 5391 5392 5393 5394 5395 5396 5397 5398 5399 5400 5401 5402 5403 5404 5405 5406 5407 5408 5409 5410 5411 5412 5413 5414 5415 5416 5417 5418 5419 5420 5421 5422 5423 5424 5425 5426 5427 5428 5429 5430 5431 5432 5433 5434 5435 5436 5437 5438 5439 5440 5441 5442 5443 5444 5445 5446 5447 5448 5449 5450 5451 5452 5453 5454 5455 5456 5457 5458 5459 5460 5461 5462 5463 5464 5465 5466 5467 5468 5469 5470 5471 5472 5473 5474 5475 5476 5477 5478 5479 5480 5481 5482 5483 5484 5485 5486 5487 5488 5489 5490 5491 5492 5493 5494 5495 5496 5497 5498 5499 5500 5501 5502 5503 5504 5505 5506 5507 5508 5509 5510 5511 5512 5513 5514 5515 5516 5517 5518 5519 5520 5521 5522 5523 5524 5525 5526 5527 5528 5529 5530 5531 5532 5533 5534 5535 5536 5537 5538 5539 5540 5541 5542 5543 5544 5545 5546 5547 5548 5549 5550 5551 5552 5553 5554 5555 5556 5557 5558 5559 5560 5561 5562 5563 5564 5565 5566 5567 5568 5569 5570 5571 5572 5573 5574 5575 5576 5577 5578 5579 5580 5581 5582 5583 5584 5585 5586 5587 5588 5589 5590 5591 5592 5593 5594 5595 5596 5597 5598 5599 5600 5601 5602 5603 5604 5605 5606 5607 5608 5609 5610 5611 5612 5613 5614 5615 5616 5617 5618 5619 5620 5621 5622 5623 5624 5625 5626 5627 5628 5629 5630 5631 5632 5633 5634 5635 5636 5637 5638 5639 5640 5641 5642 5643 5644 5645 5646 5647 5648 5649 5650 5651 5652 5653 5654 5655 5656 5657 5658 5659 5660 5661 5662 5663 5664 5665 5666 5667 5668 5669 5670 5671 5672 5673 5674 5675 5676 5677 5678 5679 5680 5681 5682 5683 5684 5685 5686 5687 5688 5689 5690 5691 5692 5693 5694 5695 5696 5697 5698 5699 5700 5701 5702 5703 5704 5705 5706 5707 5708 5709 5710 5711 5712 5713 5714 5715 5716 5717 5718 5719 5720 5721 5722 5723 5724 5725 5726 5727 5728 5729 5730 5731 5732 5733 5734 5735 5736 5737 5738 5739 5740 5741 5742 5743 5744 5745 5746 5747 5748 5749 5750 5751 5752 5753 5754 5755 5756 5757 5758 5759 5760 5761 5762 5763 5764 5765 5766 5767 5768 5769 5770 5771 5772 5773 5774 5775 5776 5777 5778 5779 5780 5781 5782 5783 5784 5785 5786 5787 5788 5789 5790 5791 5792 5793 5794 5795 5796 5797 5798 5799 5800 5801 5802 5803 5804 5805 5806 5807 5808 5809 5810 5811 5812 5813 5814 5815 5816 5817 5818 5819 5820 5821 5822 5823 5824 5825 5826 5827 5828 5829 5830 5831 5832 5833 5834 5835 5836 5837 5838 5839 5840 5841 5842 5843 5844 5845 5846 5847 5848 5849 5850 5851 5852 5853 5854 5855 5856 5857 5858 5859 5860 5861 5862 5863 5864 5865 5866 5867 5868 5869 5870 5871 5872 5873 5874 5875 5876 5877 5878 5879 5880 5881 5882 5883 5884 5885 5886 5887 5888 5889 5890 5891 5892 5893 5894 5895 5896 5897 5898 5899 5900 5901 5902 5903 5904 5905 5906 5907 5908 5909 5910 5911 5912 5913 5914 5915 5916 5917 5918 5919 5920 5921 5922 5923 5924 5925 5926 5927 5928 5929 5930 5931 5932 5933 5934 5935 5936 5937 5938 5939 5940 5941 5942 5943 5944 5945 5946 5947 5948 5949 5950 5951 5952 5953 5954 5955 5956 5957 5958 5959 5960 5961 5962 5963 5964 5965 5966 5967 5968 5969 5970 5971 5972 5973 5974 5975 5976 5977 5978 5979 5980 5981 5982 5983 5984 5985 5986 5987 5988 5989 5990 5991 5992 5993 5994 5995 5996 5997 5998 5999 6000 6001 6002 6003 6004 6005 6006 6007 6008 6009 6010 6011 6012 6013 6014 6015 6016 6017 6018 6019 6020 6021 6022 6023 6024 6025 6026 6027 6028 6029 6030 6031 6032 6033 6034 6035 6036 6037 6038 6039 6040 6041 6042 6043 6044 6045 6046 6047 6048 6049 6050 6051 6052 6053 6054 6055 6056 6057 6058 6059 6060 6061 6062 6063 6064 6065 6066 6067 6068 6069 6070 6071 6072 6073 6074 6075 6076 6077 6078 6079 6080 6081 6082 6083 6084 6085 6086 6087 6088 6089 6090 6091 6092 6093 6094 6095 6096 6097 6098 6099 6100 6101 6102 6103 6104 6105 6106 6107 6108 6109 6110 6111 6112 6113 6114 6115 6116 6117 6118 6119 6120 6121 6122 6123 6124 6125 6126 6127 6128 6129 6130 6131 6132 6133 6134 6135 6136 6137 6138 6139 6140 6141 6142 6143 6144 6145 6146 6147 6148 6149 6150 6151 6152 6153 6154 6155 6156 6157 6158 6159 6160 6161 6162 6163 6164 6165 6166 6167 6168 6169 6170 6171 6172 6173 6174 6175 6176 6177 6178 6179 6180 6181 6182 6183 6184 6185 6186 6187 6188 6189 6190 6191 6192 6193 6194 6195 6196 6197 6198 6199 6200 6201 6202 6203 6204 6205 6206 6207 6208 6209 6210 6211 6212 6213 6214 6215 6216 6217 6218 6219 6220 6221 6222 6223 6224 6225 6226 6227 6228 6229 6230 6231 6232 6233 6234 6235 6236 6237 6238 6239 6240 6241 6242 6243 6244 6245 6246 6247 6248 6249 6250 6251 6252 6253 6254 6255 6256 6257 6258 6259 6260 6261 6262 6263 6264 6265 6266 6267 6268 6269 6270 6271 6272 6273 6274 6275 6276 6277 6278 6279 6280 6281 6282 6283 6284 6285 6286 6287 6288 6289 6290 6291 6292 6293 6294 6295 6296 6297 6298 6299 6300 6301 6302 6303 6304 6305 6306 6307 6308 6309 6310 6311 6312 6313 6314 6315 6316 6317 6318 6319 6320 6321 6322 6323 6324 6325 6326 6327 6328 6329 6330 6331 6332 6333 6334 6335 6336 6337 6338 6339 6340 6341 6342 6343 6344 6345 6346 6347 6348 6349 6350 6351 6352 6353 6354 6355 6356 6357 6358 6359 6360 6361 6362 6363 6364 6365 6366 6367 6368 6369 6370 6371 6372 6373 6374 6375 6376 6377 6378 6379 6380 6381 6382 6383 6384 6385 6386 6387 6388 6389 6390 6391 6392 6393 6394 6395 6396 6397 6398 6399 6400 6401 6402 6403 6404 6405 6406 6407 6408 6409 6410 6411 6412 6413 6414 6415 6416 6417 6418 6419 6420 6421 6422 6423 6424 6425 6426 6427 6428 6429 6430 6431 6432 6433 6434 6435 6436 6437 6438 6439 6440 6441 6442 6443 6444 6445 6446 6447 6448 6449 6450 6451 6452 6453 6454 6455 6456 6457 6458 6459 6460 6461 6462 6463 6464 6465 6466 6467 6468 6469 6470 6471 6472 6473 6474 6475 6476 6477 6478 6479 6480 6481 6482 6483 6484 6485 6486 6487 6488 6489 6490 6491 6492 6493 6494 6495 6496 6497 6498 6499 6500 6501 6502 6503 6504 6505 6506 6507 6508 6509 6510 6511 6512 6513 6514 6515 6516 6517 6518 6519 6520 6521 6522 6523 6524 6525 6526 6527 6528 6529 6530 6531 6532 6533 6534 6535 6536 6537 6538 6539 6540 6541 6542 6543 6544 6545 6546 6547 6548 6549 6550 6551 6552 6553 6554 6555 6556 6557 6558 6559 6560 6561 6562 6563 6564 6565 6566 6567 6568 6569 6570 6571 6572 6573 6574 6575 6576 6577 6578 6579 6580 6581 6582 6583 6584 6585 6586 6587 6588 6589 6590 6591 6592 6593 6594 6595 6596 6597 6598 6599 6600 6601 6602 6603 6604 6605 6606 6607 6608 6609 6610 6611 6612 6613 6614 6615 6616 6617 6618 6619 6620 6621 6622 6623 6624 6625 6626 6627 6628 6629 6630 6631 6632 6633 6634 6635 6636 6637 6638 6639 6640 6641 6642 6643 6644 6645 6646 6647 6648 6649 6650 6651 6652 6653 6654 6655 6656 6657 6658 6659 6660 6661 6662 6663 6664 6665 6666 6667 6668 6669 6670 6671 6672 6673 6674 6675 6676 6677 6678 6679 6680 6681 6682 6683 6684 6685 6686 6687 6688 6689 6690 6691 6692 6693 6694 6695 6696 6697 6698 6699 6700 6701 6702 6703 6704 6705 6706 6707 6708 6709 6710 6711 6712 6713 6714 6715 6716 6717 6718 6719 6720 6721 6722 6723 6724 6725 6726 6727 6728 6729 6730 6731 6732 6733 6734 6735 6736 6737 6738 6739 6740 6741 6742 6743 6744 6745 6746 6747 6748 6749 6750 6751 6752 6753 6754 6755 6756 6757 6758 6759 6760 6761 6762 6763 6764 6765 6766 6767 6768 6769 6770 6771 6772 6773 6774 6775 6776 6777 6778 6779 6780 6781 6782 6783 6784 6785 6786 6787 6788 6789 6790 6791 6792 6793 6794 6795 6796 6797 6798 6799 6800 6801 6802 6803 6804 6805 6806 6807 6808 6809 6810 6811 6812 6813 6814 6815 6816 6817 6818 6819 6820 6821 6822 6823 6824 6825 6826 6827 6828 6829 6830 6831 6832 6833 6834 6835 6836 6837 6838 6839 6840 6841 6842 6843 6844 6845 6846 6847 6848 6849 6850 6851 6852 6853 6854 6855 6856 6857 6858 6859 6860 6861 6862 6863 6864 6865 6866 6867 6868 6869 6870 6871 6872 6873 6874 6875 6876 6877 6878 6879 6880 6881 6882 6883 6884 6885 6886 6887 6888 6889 6890 6891 6892 6893 6894 6895 6896 6897 6898 6899 6900 6901 6902 6903 6904 6905 6906 6907 6908 6909 6910 6911 6912 6913 6914 6915 6916 6917 6918 6919 6920 6921 6922 6923 6924 6925 6926 6927 6928 6929 6930 6931 6932 6933 6934 6935 6936 6937 6938 6939 6940 6941 6942 6943 6944 6945 6946 6947 6948 6949 6950 6951 6952 6953 6954 6955 6956 6957 6958 6959 6960 6961 6962 6963 6964 6965 6966 6967 6968 6969 6970 6971 6972 6973 6974 6975 6976 6977 6978 6979 6980 6981 6982 6983 6984 6985 6986 6987 6988 6989 6990 6991 6992 6993 6994 6995 6996 6997 6998 6999 7000 7001 7002 7003 7004 7005 7006 7007 7008 7009 7010 7011 7012 7013 7014 7015 7016 7017 7018 7019 7020 7021 7022 7023 7024 7025 7026 7027 7028 7029 7030 7031 7032 7033 7034 7035 7036 7037 7038 7039 7040 7041 7042 7043 7044 7045 7046 7047 7048 7049 7050 7051 7052 7053 7054 7055 7056 7057 7058 7059 7060 7061 7062 7063 7064 7065 7066 7067 7068 7069 7070 7071 7072 7073 7074 7075 7076 7077 7078 7079 7080 7081 7082 7083 7084 7085 7086 7087 7088 7089 7090 7091 7092 7093 7094 7095 7096 7097 7098 7099 7100 7101 7102 7103 7104 7105 7106 7107 7108 7109 7110 7111 7112 7113 7114 7115 7116 7117 7118 7119 7120 7121 7122 7123 7124 7125 7126 7127 7128 7129 7130 7131 7132 7133 7134 7135 7136 7137 7138 7139 7140 7141 7142 7143 7144 7145 7146 7147 7148 7149 7150 7151 7152 7153 7154 7155 7156 7157 7158 7159 7160 7161 7162 7163 7164 7165 7166 7167 7168 7169 7170 7171 7172 7173 7174 7175 7176 7177 7178 7179 7180 7181 7182 7183 7184 7185 7186 7187 7188 7189 7190 7191 7192 7193 7194 7195 7196 7197 7198 7199 7200 7201 7202
|
\start
Date: Mon, 01 Jan 2007 21:27:18 +0100
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: version 107 of trunk
>> I have seen your definitions of Partial and Generator before, but I am not
>> quite sure whether they are needed.
> Yes, I need them, since I don't want to create all the 848456353 binary forests
> at once.
I think you forgot to tell the number of nodes for the above number. ;-)
Well, it is clear that you don't want to reserve so much memory at once.
But I don't have any idea how to do this nicely. That is the reason, why
this mail also goes to axiom-developer.
The problem is in aldor-combinat we have huge structures which are
generated on the fly and generated on demand in a "Generator" structure.
So we have a function
structures: SetSpecies(L) -> Generator %
The problem now is, if I call "g := structures(s)" inside an Axiom
session, one cannot simply step this generator in a form like
for x in g repeat {...}
Is there somebody knowing the internals of Axiom (and maybe Aldor) who
could help to make such a "for" statement work?
\start
Date: 02 Jan 2007 16:44:11 +0100
From: Francois Maltey
To: list
Subject: Conditional for inner functions in a package.
First, H-A-P-P-Y new YEAR 2007 for everybody !
A *.spad file can cantain conditionals as
...
if R is Integer then
aFunction x == a definition for integer
else
aFunction x == an other definition
...
But the function << aFunction >> must be an exported function.
If aFunction is a local function in the package the test is always false.
So some packages export a lot of local functions, by example elemntry.spad.
[axiom] )sh EF
all the ixxx functions might be inner functions because
they are defined after a conditional.
The file elmentry.spad explains :
-- the following should be local, but are conditional
I can't find any advice about it in the 30-year book.
Where is the problem ? What can aldor do ?
Export too much functions complicate the use of axiom.
You can test this very short package for expression
-------------------------------------------------------------------
)abbrev package TRYCOND TryConditions
TryConditions (R, F): Exports == Implementation where
R : Join (OrderedSet, GcdDomain)
F : Join (FunctionSpace R, TranscendentalFunctionCategory)
Exports ==> with
result : F -> F
expResult : F -> F
Implementation ==> add
iResult : F -> F
iResult x == cos x
expResult x == cos x
if R is Integer then
iResult x == sin x
expResult x == sin x
result x == iResult x
----------------------------------------------------------------------
test
result (sin x) -- sin : right
result (sin %i) -- sin, I wait a cos
expResult (sin x) -- sin : right
expResult (sin %i) -- cos : right
\start
Date: Tue, 02 Jan 2007 21:38:09 +0100
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: version 107 of trunk
On 01/01/2007 10:36 PM, Martin Rubey wrote:
> Ralf Hemmecke writes:
>
>>>> I have seen your definitions of Partial and Generator before, but I am not
>>>> quite sure whether they are needed.
>>> Yes, I need them, since I don't want to create all the 848456353 binary
>>> forests
>>> at once.
>> Actually, that doesn't mean that you have to define Partial or Generator.
>>
>> If you look more closely, you use "extend Generator" in axcombat2.as (trunk
>> r109), i.e. Generator is already existing.
>
> Well, yes and no. Generator exists only in libaldor. extending Generator makes
> it visible to axiom.
That is interesting. But it only says that you cannot assign a Generator
object to a variable (I believe). However, try the following code with
%axiom
)co aaa.as
l: List Integer := [2,3,5]
neg gen l
---BEGIN aaa.as
#include "axiom"
PkgA: with {
gen: List Integer -> Generator Integer;
neg: Generator Integer -> List List Integer;
} == add {
gen(l: List Integer): Generator Integer == generator l;
neg(g: Generator Integer): List List Integer == {
import from List Integer;
[[x] for x in g];
}
}
---END aaa.as
\start
Date: Wed, 03 Jan 2007 00:31:21 +0100
From: Ralf Hemmecke
To: Francois Maltey
Subject: Re: Conditional for inner functions in a package.
Hello Francois and Happy New Year to everyone.
I am not a SPAD-expert, but let me try on your little code chunk.
> -------------------------------------------------------------------
> )abbrev package TRYCOND TryConditions
>
> TryConditions (R, F): Exports == Implementation where
> R : Join (OrderedSet, GcdDomain)
> F : Join (FunctionSpace R, TranscendentalFunctionCategory)
>
> Exports ==> with
> result : F -> F
> expResult : F -> F
>
> Implementation ==> add
> iResult : F -> F
> iResult x == cos x
> expResult x == cos x
> if R is Integer then
> iResult x == sin x
> expResult x == sin x
> result x == iResult x
> ----------------------------------------------------------------------
> test
> result (sin x) -- sin : right
> result (sin %i) -- sin, I wait a cos
> expResult (sin x) -- sin : right
> expResult (sin %i) -- cos : right
First, to me that is bad code in the sense that "==" should define a
constant. What you do is you define the constan iResult and if "R is
Integer" you re-define the "constant". Looks ugly, better would be
if R is Integer
then expResult x == sin
else expResult x == cos
Aldor has a "local" keyword, but I have not tried to actually
conditionalize the definition of a local constant.
My construction above for exported functions is certainly treated in a
special way by the compiler.
What you want is
result(x: F): F == if R has IntegerNumberSystem then sin x else cos x;
right? So why don't you write it?
Ok, now everytime "result" is called the expression
R has IntegerNumberSystem
will be evaluated. Since that is a waste of time, you could say
RhasINS: Boolean == R has IntegerNumberSystem;
result(x: F): F == if RhasINS then sin x else cos x;
which is only a bit test. But probably still one test too much.
If I look at elemntry.spad, it seems that all the functions starting
with ii... should be defined in a separate package. Let's name it
MyTrigFuns(R, F). MyTrigFuns should export all these ii... functions.
and define them as in ElementaryFunction(R,F). ElementaryFunctions in
turn should have all the i... and ii... stuff moved to MyTrigFuns and at
the end always say something like
evaluate(opexp, iiexp$MyTrigFuns(R, F))
My problem would be how to avoid the exports of MyTrigFuns to be visible
in an Axiom session. But maybe
)unexpose MyTrigFuns
works.
Otherwise you could define MyTrigFuns locally inside the "add" of
ElementaryFunctions. So no exports of i... functions would be seen in an
Axiom session since they are hidden inside the "add". Aldor would allow
such a local domain construction. I have however no idea whether SPAD
can do this.
I hope I could help a little.
\start
Date: Tue, 2 Jan 2007 21:59:50 -0500
From: Bill Page
To: list
Subject: undocument "pattern matching" operator in Axiom interpreter
I have not been able to find any documentation about the use
of "is" in the Axiom interpreter. For example:
(1) -> [1,2,3] is [a,b,c]
(1) true
Type: Boolean
(2) -> a
(2) 1
Type: PositiveInteger
(3) -> b
(3) 2
Type: PositiveInteger
(4) -> c
(4) 3
Type: PositiveInteger
(5) -> [1,2,3] is [x,y]
(5) false
Type: Boolean
(6) -> x
(6) x
Type: Variable x
(7) -> y
(7) y
Type: Variable y
(8) -> [x,y] is [1,2]
Pattern matching is only allowed on lists.
(9) -> )di op is
is is not a known function. AXIOM will try to list its functions
which contain is in their names. This is the same output you
would get by issuing
)what operations is
(10) -> [[1,2],[3,4]] is [p,q]
(10) true
Type: Boolean
(11) -> p,q
(11) [[1,2],[3,4]]
Type: Tuple List PositiveInteger
(12) -> p
(12) [1,2]
Type: List PositiveInteger
(13) -> [[1,2],[3,4]] is [[p1,p2],[q1,q2]]
(13) true
Type: Boolean
(14) -> p1
(14) 1
Type: PositiveInteger
(15) -> [[1,2],[3,4]] is [[x1,x2],y0]
(15) true
Type: Boolean
(16) -> y0
(16) [3,4]
Type: List PositiveInteger
(17) -> ...
Does anyone know where I can find out how to use "is" in the
interpreter? Where is this defined in the the interpreter source
code? Is this operator also defined in the SPAD language?
\start
Date: 03 Jan 2007 11:19:20 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: undocument "pattern matching" operator in Axiom interpreter
Cc: list
Bill Page writes:
| I have not been able to find any documentation about the use
| of "is" in the Axiom interpreter. For example:
[...]
| Does anyone know where I can find out how to use "is" in the
| interpreter? Where is this defined in the the interpreter source
| code? Is this operator also defined in the SPAD language?
Two weeks ago, while looking at the "new compiler parser", I became
aware that new Boot's "is" and "isnt" are part of SPAD. Have a look
at the parsing function npMatch in src/interp/cparse.boot.
-- Gaby
\start
Date: Wed, 03 Jan 2007 18:10:05 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: Re: undocument "pattern matching" operator in Axiom interpreter
[...]
> Does anyone know where I can find out how to use "is" in the
> interpreter? Where is this defined in the the interpreter source
> code?
What you are looking for can be found in i-spec1.boot and i-spec2.boot
("upis" in your case ("up" - "is")). The "real" job is in i-analy.boot.
This is where the function "upis" is called . See the function bottomUp
and more precisely the line that contains:
(fn:= GET(opName,"up")) and (u:= FUNCALL(fn, t)) => u
Greg
PS: Don't ask me how to use "is" in the interpreter, I don't know :-).
\start
Date: 03 Jan 2007 19:02:20 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: undocument "pattern matching" operator in Axiom interpreter
Gabriel Dos Reis writes:
| Bill Page writes:
|
| | I have not been able to find any documentation about the use
| | of "is" in the Axiom interpreter. For example:
|
| [...]
|
| | Does anyone know where I can find out how to use "is" in the
| | interpreter? Where is this defined in the the interpreter source
| | code? Is this operator also defined in the SPAD language?
|
| Two weeks ago, while looking at the "new compiler parser", I became
| aware that new Boot's "is" and "isnt" are part of SPAD. Have a look
| at the parsing function npMatch in src/interp/cparse.boot.
In fact, "is" and "isnt" are also implemented by the interpreter and
the old SPAD compiler. See src/interp/parini.boot and
src/interp/property.lisp.
\start
Date: Wed, 3 Jan 2007 23:17:42 +0100 (CET)
From: Franz Lehner
To: list
Subject: How to do generic sum using aldor?
Hello
what is wrong with the following code:
----------------------------------------------------------------
#include "axiom"
extend List (R:Ring) : with {
sumlist:(ll: %)->R;
} == {add {
sumlist ( ll: %) : R == {
s: R :=0;
for x:R in generator ll repeat s:= s+x;
return s
}
}
}
----------------------------------------------------------------
it compiles fine, but then I get
(1) -> sumlist [1,2,3]
1) ->
>> System error:
Caught fatal error [memory may be damaged]
this happens on debian stable, Axiom+Aldor from April 2006,
(axiom-aldor-20060621.tgz as available on axiom-developer.org).
I was wondering how to implement a "generic" sumlist function.
\start
Date: Wed, 03 Jan 2007 23:39:50 +0100
From: Ralf Hemmecke
To: Franz Lehner
Subject: Re: How to do generic sum using aldor?
You should have read previous posts. Axiom does not understand "extend".
The following code does what you want. Just say
%axiom
)co sumlist.as
sumlist [1,2,3]
---BEGIN sumlist.as
#include "axiom"
SumPackage(R: Ring): with {
sumlist: List R -> R;
} == add {
sumlist (l: List R): R == {
s: R := 0;
for x in l repeat s:= s+x;
return s
}
}
---END sumlist.as
\start
Date: Thu, 4 Jan 2007 05:35:54 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Complex argument
Current version of complex argument (in gaussian.spad.pamphlet) is
responsible for multiple bugs (15, 47, 184, 293, 314 and a few wrong
answers in mapleok.output). The patch below uses more complicated
but correct formula for complex argument.
The existing formula assumed that x has positive real part. But
for integration it is typical to have constant imaginary part
and real part which changes sign. So the existing formula produced
spurious jump discontinuities.
With the patch Axiom gives now correct answers for most such problems.
Unfortunatly, correct answer is more complicated and ATM Axiom is
unable to simplify it. Because of this some test outputs (especially
in mapleok.output) got bigger -- I am still checking if all new
results correct.
In principle we could try to determine when the old formula works
correctly -- we should be able to determine in which a constant
lives and for many functions it is also possible to prove that
the function has constant sign. OTOH such machinery belongs to
other packages. In fact we have various sign finding utilities
which work on expressions, but:
- sign finding may be pretty expensive
- it is not clear if such utilities are applicable to all
domains allowed as arguments to complex (which probably
means that we need to add a maze of conditionals choosing
correct version of 'argument')
Also, currently integrator converts exponentials and logarithms
to trigonometric and arc trigonometric functions by taking
real part of the answer -- this looks wrong for me.
Anyway, the patch follows:
diff -u wh-sandbox2.bb/src/algebra/gaussian.spad.pamphlet wh-sandbox2/src/algebra/gaussian.spad.pamphlet
--- wh-sandbox2.bb/src/algebra/gaussian.spad.pamphlet 2006-12-03 04:23:11.000000000 +0100
+++ wh-sandbox2/src/algebra/gaussian.spad.pamphlet 2007-01-03 18:01:06.000000000 +0100
@@ -367,10 +367,18 @@
argument x == atan2loc(imag x, real x)
else
- -- Not ordered so dictate two quadrants
- argument x ==
- zero? real x => pi()$R * half
- atan(imag(x) * recip(real x)::R)
+ if R has RadicalCategory then
+ argument x ==
+ n1 := sqrt(norm(x))
+ x1 := real(x) + n1
+ (2::R)*atan(imag(x) * recip(x1)::R)
+
+ else
+ -- Emulate sqrt using exp and log
+ argument x ==
+ n1 := exp(half*log(norm(x)))
+ x1 := real(x) + n1
+ (2::R)*atan(imag(x) * recip(x1)::R)
pi() == pi()$R :: %
\start
Date: Thu, 4 Jan 2007 05:47:29 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Zero divisors in Expression Integer
I have already written that due to incomplte simplification we
may get zero divisors in Expression Integer. Below an easy
example that multiplication in Expression Integer is nonassociative
(or, if you prefer, a proof that 1 equals 0):
(135) -> c1 := sqrt(2)*sqrt(3*x)+sqrt(6*x)
+--+ +-+ +--+
(135) \|6x + \|2 \|3x
Type: Expression Integer
(136) -> c2 := sqrt(2)*sqrt(3*x)-sqrt(6*x)
+--+ +-+ +--+
(136) - \|6x + \|2 \|3x
Type: Expression Integer
(137) -> (1/c1)*c1*c2*(1/c2)
(137) 1
Type: Expression Integer
(138) -> (1/c1)*(c1*c2)*(1/c2)
(138) 0
Type: Expression Integer
BTW, a similar looking constant expression throws an error:
(139) -> 1/(sqrt(2)*sqrt(3)+sqrt(6))
>> Error detected within library code:
univariate: denominator is 0 mod p
\start
Date: Thu, 04 Jan 2007 01:31:13 -0500
From: William Sit
To: Waldek Hebisch
Subject: Re: Zero divisors in Expression Integer
On Thu, 4 Jan 2007 05:47:29 +0100 (CET)
Waldek Hebisch wrote:
>I have already written that due to incomplte
>simplification we
>may get zero divisors in Expression Integer. Below an
>easy
>example that multiplication in Expression Integer is
>nonassociative
>(or, if you prefer, a proof that 1 equals 0):
>
>(135) -> c1 := sqrt(2)*sqrt(3*x)+sqrt(6*x)
>
> +--+ +-+ +--+
> (135) \|6x + \|2 \|3x
> Type:
>Expression Integer
>(136) -> c2 := sqrt(2)*sqrt(3*x)-sqrt(6*x)
>
> +--+ +-+ +--+
> (136) - \|6x + \|2 \|3x
> Type:
>Expression Integer
>(137) -> (1/c1)*c1*c2*(1/c2)
>
> (137) 1
> Type:
>Expression Integer
>(138) -> (1/c1)*(c1*c2)*(1/c2)
>
> (138) 0
> Type:
>Expression Integer
But this is not just an Axiom problem. Mathematica does
the same thing, with a slight variation on input:
a1 = Sqrt[2]*Sqrt[3 Sqrt[5x + 7] + 6] - Sqrt[6Sqrt[5x + 7]
+ 12]
a2 = Sqrt[2]*Sqrt[3 Sqrt[5x + 7] + 6] + Sqrt[6Sqrt[5x + 7]
+ 12]
(1/a1)*a1*a2*(1/a2) (* answer 1 *)
(1/a1)*(a1*a2 // Simplify)*(1/a2) (*answer 0, Simplify is
needed to get this *)
The problem seems to be the lack of a canonical form for
radical expressions and an algorithm to reduce expressions
to canonical form. A related problem is lack of algorithm
to test zero. Another is denesting of a nested radical
expression. These problems have been studied by Zippel,
Landau, Tulone et al, Carette and others.
\start
Date: Thu, 04 Jan 2007 08:34:55 +0100
From: Gernot Hueber
To: Ralf Hemmecke
Subject: Re: How to do generic sum using aldor?
Cc: Franz Lehner
You also can use reduce. E.g. reduce(+, [1,2,3])
Gernot
Ralf Hemmecke writes:
> You should have read previous posts. Axiom does not understand "extend".
>
> The following code does what you want. Just say
>
> %axiom
> )co sumlist.as
> sumlist [1,2,3]
>
> ---BEGIN sumlist.as
> #include "axiom"
> SumPackage(R: Ring): with {
> sumlist: List R -> R;
> } == add {
> sumlist (l: List R): R == {
> s: R := 0;
> for x in l repeat s:= s+x;
> return s
> }
> }
> ---END sumlist.as
\start
Date: Thu, 04 Jan 2007 09:42:15 +0100
From: Ralf Hemmecke
To: Gernot Hueber
Subject: Re: How to do generic sum using aldor?
Cc: Franz Lehner
On 01/04/2007 08:34 AM, Gernot Hueber wrote:
> You also can use reduce. E.g. reduce(+, [1,2,3])
> Gernot
Yes, but be careful. The documentation in Collection(S) (aggcat.spad) says:
reduce: ((S,S)->S,%) -> S
++ reduce(f,u) reduces the binary operation f across u. For example,
++ if u is \axiom{[x,y,...,z]} then \axiom{reduce(f,u)} returns
++ \axiom{f(..f(f(x,y),...),z)}.
++ Note: if u has one element x, \axiom{reduce(f,u)} returns x.
++ Error: if u is empty.
Franz has a bit more information on S. He knows that it is at least a
Ring, so "sumlist []" will return 0. Otherwise one would have to use
reduce: ((S,S)->S,%,S) -> S
++ reduce(f,u,x) reduces the binary operation f across u, where x is
++ the identity operation of f.
++ Same as \axiom{reduce(f,u)} if u has 2 or more elements.
++ Returns \axiom{f(x,y)} if u has one element y,
++ x if u is empty.
++ For example, \axiom{reduce(+,u,0)} returns the
++ sum of the elements of u.
\start
Date: Thu, 4 Jan 2007 11:57:58 +0100 (CET)
From: Franz Lehner
To: Ralf Hemmecke
Subject: Re: How to do generic sum using aldor?
On Wed, 3 Jan 2007, Ralf Hemmecke wrote:
thanks for all the answers.
> You should have read previous posts. Axiom does not understand "extend".
I was confused.
I read the excellent aldor user's guide and neglected the fact, that
it is written for the standalone version of aldor rather than the axiom
version. Is there a similar manual for axiom+aldor other than
http://www.aldor.org/docs/HTML/chap18.html ?
Is this the right mailing list anyways?
I started a project in axiom some time ago (computations in group rings
with arbitrary coefficient rings, which is not possible in gap, tedious
to impossible in maple/mathematica and very simple in axiom). Since the
old compiler will disappear at some point I decided to switch to aldor
starting by a translation of what I had already written and stumbled on
the summation problem.
Now to the real questions.
I was aware of reduce but did not use it because I actually wanted to
write a "generic" sum function for "all" possible structures, including
finite streams etc. on which reduce does not work.
The only way I found in axiom was
last complete scan(0,+,somestream)
which looks rather insatisfactory.
What could be axiom equivalents of AdditiveType and
BoundedFiniteDataStructureType ?
Then SumPackage(L:BoundedFiniteDataStructureType,R:AdditiveType)
with essentially the same code would do just any possible case.
\start
Date: Thu, 04 Jan 2007 13:04:14 +0100
From: Christian Aistleitner
To: list
Subject: Using Aldor compiler from within Axiom on amd64
Dear list,
I installed the binary Axiom+Aldor package from
http://wiki.axiom-developer.org/Mirrors?go=/public/axiom-aldor-2006062=
1.tgz&it=Axiom+with+Aldor+binary
according to the instructions on
http://wiki.axiom-developer.org/AxiomBinaries
on my gentoo amd64 system.
Compiling the following short snippet (as test.as)
#include "axiom"
f():OutputForm == {
import from Integer;
outputForm 1;
}
within Axiom, gives no error. But when calling the function f after
compilation, I get
>> System error:
Unknown bfd format
. How can I get Axiom to run code that got compiled from within Axiom
using the Aldor compiler?
Let me now give you more details about the setup:
I know the downloaded file is a 32bit binary, but I have the appropriate
32bit libraries installed on my system:
____________________________________________
tmgisi@spencer
cwd: ~/axiom
ldd /home/tmgisi/axiomaldor/axiom/mnt/linux/bin/AXIOMsys
linux-gate.so.1 => (0xffffe000)
libm.so.6 => /lib32/libm.so.6 (0xf7ec5000)
libgmp.so.3 => /lib32/libgmp.so.3 (0xf7e90000)
libreadline.so.4 => /emul/linux/x86/lib/libreadline.so.4
(0xf7e64000)
libncurses.so.5 => /emul/linux/x86/lib/libncurses.so.5 (0xf7e23000)
libc.so.6 => /lib32/libc.so.6 (0xf7cfa000)
/lib/ld-linux.so.2 (0xf7f0e000)
libgpm.so.1 => /emul/linux/x86/lib/libgpm.so.1 (0xf7cf4000)
.
The binary has been unpacked to
/home/tmgisi/axiomaldor/
and the setup followed the instruction on the web page mentioned above
____________________________________________
tmgisi@spencer
cwd: ~/axiom
export AXIOM=/home/tmgisi/axiomaldor/axiom/mnt/linux
____________________________________________
tmgisi@spencer
cwd: ~/axiom
export PATH=$AXIOM/bin:$PATH
____________________________________________
tmgisi@spencer
cwd: ~/axiom
export ALDORROOT=/home/tmgisi/axiomaldor/aldor/linux/1.0.2
____________________________________________
tmgisi@spencer
cwd: ~/axiom
export PATH=$ALDORROOT/bin:$PATH
____________________________________________
tmgisi@spencer
cwd: ~/axiom
cat test.as
#include "axiom"
f():OutputForm == {
import from Integer;
outputForm 1;
}
____________________________________________
tmgisi@spencer
cwd: ~/axiom
AXIOMsys
AXIOM Computer Algebra System
Version: Axiom (April 2006)
Timestamp: Wednesday June 21, 2006 at 03:45:56
------------------------------------------------------------------------=
-----
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave AXIOM and return to shell.
------------------------------------------------------------------------=
-----
Re-reading compress.daase Re-reading interp.daase
Re-reading operation.daase
Re-reading category.daase
Re-reading browse.daase
(1) -> )co test.as
Compiling AXIOM source code from file test.as using AXIOM-XL
compiler and options
-O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y
$AXIOM/algebra
Use the system command )set compiler args to change these
options.
#1 (Warning) Deprecated message prefix: use `ALDOR_' instead of `_AXL'
Compiling Lisp source code from file ./test.lsp
Issuing )library command for test
Reading /home/tmgisi/axiom/test.asy
Loading /home/tmgisi/axiomaldor/axiom/mnt/linux/autoload/bc-matrix.
Loading /home/tmgisi/axiomaldor/axiom/mnt/linux/autoload/bc-misc.
Loading /home/tmgisi/axiomaldor/axiom/mnt/linux/autoload/bc-solve.
Loading /home/tmgisi/axiomaldor/axiom/mnt/linux/autoload/bc-util.
Loading /home/tmgisi/axiomaldor/axiom/mnt/linux/autoload/ht-util.
Loading /home/tmgisi/axiomaldor/axiom/mnt/linux/autoload/htsetvar.
Loading /home/tmgisi/axiomaldor/axiom/mnt/linux/autoload/ht-root.
Loading /home/tmgisi/axiomaldor/axiom/mnt/linux/autoload/br-con.
Loading /home/tmgisi/axiomaldor/axiom/mnt/linux/autoload/br-data.
Loading /home/tmgisi/axiomaldor/axiom/mnt/linux/autoload/showimp.
Loading /home/tmgisi/axiomaldor/axiom/mnt/linux/autoload/br-op1.
Loading /home/tmgisi/axiomaldor/axiom/mnt/linux/autoload/br-op2.
Loading /home/tmgisi/axiomaldor/axiom/mnt/linux/autoload/br-search.
Loading /home/tmgisi/axiomaldor/axiom/mnt/linux/autoload/br-util.
Loading /home/tmgisi/axiomaldor/axiom/mnt/linux/autoload/topics.
Loading /home/tmgisi/axiomaldor/axiom/mnt/linux/autoload/br-prof.
Loading /home/tmgisi/axiomaldor/axiom/mnt/linux/autoload/br-saturn.
(1) -> f()
>> System error:
Unknown bfd format
(1) -> )quit
Please enter y or yes if you really want to leave the interactive
environment and return to the operating system:
y
\start
Date: Thu, 04 Jan 2007 13:36:15 +0100
From: Ralf Hemmecke
To: Franz Lehner
Subject: Re: How to do generic sum using aldor?
> I read the excellent aldor user's guide and neglected the fact, that
> it is written for the standalone version of aldor rather than the axiom
> version. Is there a similar manual for axiom+aldor other than
> http://www.aldor.org/docs/HTML/chap18.html ?
> Is this the right mailing list anyways?
Since you want to work with Axiom, I guess you are right here.
[snip]
> Now to the real questions.
> I was aware of reduce but did not use it because I actually wanted to
> write a "generic" sum function for "all" possible structures, including
> finite streams etc. on which reduce does not work.
> The only way I found in axiom was
>
> last complete scan(0,+,somestream)
>
> which looks rather insatisfactory.
I currently rather rely on what is provided in LibAldor+LibAlgebra and
don't take things from LibAxiom, but that is personal taste.
It seems that you want
---BEGIN sum.as
#include "axiom"
macro {
MyAdditiveMonoid == with {
0: %;
+: (%, %) -> %;
}
}
SumPackage(M: MyAdditiveMonoid): with {
sum: Generator M -> M;
} == add {
sum(g: Generator M): M == {
m: M := 0;
for x in g repeat m := m+x;
return m;
}
}
---END sum.as
You would call that via
l: List Integer := [2,3,4]
sum generator l
You have probably read that "Generator" abstracts from the actual
underlying datastructure and only relies on the fact that the elements
are delivered in a linear fashion. The bad thing is: "Generator" is not
available in an Axiom Session. And even worse, no Axiom domain provides
a "generator" function for its elements.
You always have to hide it inside an Aldor program. So your problem is
probably not easily solvable. But that would be my Aldor approach.
> What could be axiom equivalents of AdditiveType and
> BoundedFiniteDataStructureType?
I don't know of any "Bounded..." category in Axiom.
> Then SumPackage(L:BoundedFiniteDataStructureType,R:AdditiveType)
> with essentially the same code would do just any possible case.
Yep. But sorry to say: Axiom is weak in that respect (at least to my
knowledge).
\start
Date: Thu, 4 Jan 2007 15:06:07 +0100 (CET)
From: Franz Lehner
To: Ralf Hemmecke
Subject: Re: How to do generic sum using aldor?
On Thu, 4 Jan 2007, Ralf Hemmecke wrote:
> Since you want to work with Axiom, I guess you are right here.
well, there is also axiom-math and axiom-mail ... anyways the people who
answer seem to be the same:)
> I currently rather rely on what is provided in LibAldor+LibAlgebra and don't
> take things from LibAxiom, but that is personal taste.
I wasn't aware that this is possible.
Using #include "aldor" and #include "algebra" compiles but won't run:
(1) -> sum [1,2,3]
>> System error:
AxiomXL file "sal_list" is missing!
how can one mix axiom and libaldor?
> You would call that via
>
> l: List Integer := [2,3,4]
> sum generator l
yes, this looked elegant and promising.
> Yep. But sorry to say: Axiom is weak in that respect (at least to my
> knowledge).
ok, at least this is an answer and I shall not try further.
Thus my "SumPackage" includes also
sum ( ll: Stream R) : R == {
import from StreamFunctions2(R,R);
last complete scan(0,+, ll);
}
Is it really true that StreamFunctions2 must explicitly be imported?
The "last complete scan" makes me worry if the stream is really long
and all intermediate results are stored; or is it optimized away by the
compiler?
I rather would like the for loop but do not know where to import it from.
greping the source files is not really helpful in this case ...
\start
Date: Thu, 4 Jan 2007 15:46:56 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Re: Zero divisors in Expression Integer
William wrote:
> Waldek Hebisch wrote:
> >I have already written that due to incomplte
> >simplification we
> >may get zero divisors in Expression Integer. Below an
> >easy
> >example that multiplication in Expression Integer is
> >nonassociative
> >(or, if you prefer, a proof that 1 equals 0):
> >
> >(135) -> c1 := sqrt(2)*sqrt(3*x)+sqrt(6*x)
> >
> > +--+ +-+ +--+
> > (135) \|6x + \|2 \|3x
> > Type:
> >Expression Integer
> >(136) -> c2 := sqrt(2)*sqrt(3*x)-sqrt(6*x)
> >
> > +--+ +-+ +--+
> > (136) - \|6x + \|2 \|3x
> > Type:
> >Expression Integer
> >(137) -> (1/c1)*c1*c2*(1/c2)
> >
> > (137) 1
> > Type:
> >Expression Integer
> >(138) -> (1/c1)*(c1*c2)*(1/c2)
> >
> > (138) 0
> > Type:
> >Expression Integer
>
> But this is not just an Axiom problem. Mathematica does
> the same thing, with a slight variation on input:
> a1 = Sqrt[2]*Sqrt[3 Sqrt[5x + 7] + 6] - Sqrt[6Sqrt[5x + 7]
> + 12]
> a2 = Sqrt[2]*Sqrt[3 Sqrt[5x + 7] + 6] + Sqrt[6Sqrt[5x + 7]
> + 12]
> (1/a1)*a1*a2*(1/a2) (* answer 1 *)
> (1/a1)*(a1*a2 // Simplify)*(1/a2) (*answer 0, Simplify is
> needed to get this *)
>
Well, if you do simplification by hand, then my example give
the same result in Maple, Maxima and giac. But AFAICS
Axiom situation is worse, because the simplification is
done automatically (apparently the other systems calculate in
a ring without zero divisors and only simplify the final answer,
which is sound). Also, Axiom may automatically introduce
roots even if original input contained none. Anyway, I think
that in 2007 we should do better.
> The problem seems to be the lack of a canonical form for
> radical expressions and an algorithm to reduce expressions
> to canonical form. A related problem is lack of algorithm
> to test zero. Another is denesting of a nested radical
> expression. These problems have been studied by Zippel,
> Landau, Tulone et al, Carette and others.
>
I think that the core problem is that roots in computer algebra
are really ill-defined. For well-defined non-nested roots already
in 1971 Fateman gave resonable solution. General well-defined
roots can be resolved via factorization in algebraic extensions
(factorization is expensive, but seem to work reasonably well in
Axiom).
More precisely, one possibility is that say sqrt(x+1) is just
a solution of the equation y^2 - x - 1 = 0. Analytically,
then sqrt(x+1) is a multivalued analytic function with a
single finite branch point at x = -1 (and the second branch
point at infinity). Algebraically, P(y) = y^2 - x - 1 is
an irreducible polymomial over Q(x) and we get a well defined
quadratic extension. Large part of Axiom assumes such an
interpretation.
If we look at sqrt(2)*sqrt(3*x)-sqrt(6*x) we see that
P(y) = y^2 - 6*x splits over Q(x, sqrt(2), sqrt(3*x)). To
have a field we should either (more or less arbitrarily)
choose one of roots (factors) or reject the input or split
computation into two branches (introduce provisos).
There is an extra difficulty: traditional numerical definitions
of elementary functions have branch cuts. Branch cuts means
that we no longer have analytic functions and we may get
zero divisors even if algebraic approach would produce unique
answer.
Branch cuts turn decidable problem into undecidable one:
Claim1: Let A be an algebra of complex functions closed under +, -, *
and composition.
Assume that A contains rational constants, pi, x, sin, and sqrt (with
branch cut along negative half-axis). Then the following questions are
undecidable:
1) is an element of A zero for all x?
2) is real part of an element of A always positive?
Proof: Let phi(t) = sqrt(sqrt(t^4)) and s(x)=sin(pi*x_1)*...*sin(pi*x_n).
Consider multivariate functions of the
form f = phi(P_1(x))+phi(P_2*s(x))+phi(s(x)) - 1. Like in Richardson
proof for any multivariate polynomial Q we can make an f which
has real part positive if and only if Q has no integral zero
(Richardson used more complicated Q, but thanks to Matiasevitch it
is enough to consider polymomial Q). Then we get the conclusion the
same way as Richardson.
Remark: We can use phi(t) - t to produce zero divisors in the algebra A
(that is why I omitted division from the signature).
----------
Claim2: Let K be a differential field with field of constants k.
Assume that K = k(u_1, ..., u_n) is given as a tower of extensions
such that each u_i satisfies one of the following:
1) P(u_i) = 0 where P is an irreducible polynomial over
k(u_1,...,u_(i-1))
2) D u_i = (Df) u_i with f in k(u_1,...,u_(i-1))
3) D u_i = (Df)/f with f in k(u_1,...,u_(i-1))
in cases 2 and 3 we assume that u_i is transcendental over
k(u_1,...,u_(i-1)). Assume also that k is effectively computable.
Then K is effectively computable and given an equation for u of the form
D u (Df) u or D u (Df)/f with f in K there is an algorithm which either
finds out an algebraic extension of K containinig u solving the
equation of proves that adding transcendental u satifying the equation
does not add new constants. We can also decide if a given
polynomial is irreducible over K.
Proof: The claim is just a restatement of Risch stucture theorem
plus known (and implemented in Axiom) algorithms for computation
in algebraic extensions.
-----
Claim2 means that computation with elementary functions in algebraic
setup may be done effectively as long as we do not get into trouble
due to constants (and if Schanuel conjecture is true also computation
with constants is effective). In practice, regardless of Schanuel
conjecture we may use floating point computations to prove that
a constant is non-zero or to get an indication that with high
probability it is indeed zero.
Coming back to Axiom expressions: the theoretical basis for Expression
domain is a theorem that any finitly generated field K has form:
K = k(u_1, ..., u_m, u_{m+1},..., u_n)
where k is a prime field, u_1, ..., u_m are algebraicaly independent
(so k(u_1, ..., u_m) is just the field of rational functions) and
u_{m+1},..., u_n correspond to a tower of algebraic extensions. In
particular, we should know the minimal polynomial of u_l over
k(u_1, ..., u_{l-1}) for l = m+1, ..., n.
So, one way to solve zero divisor Expression problem is to rewrite
all kernels in terms of a set of algbraically independent kernels
and a set of "independent" algebraics. We can use Risch structure
theorem and factorization in algebraic extensions to find out
such independent sets as long as we limit ourselfs to elementary
functions. Unfortunatly, the situation with special functions
in much less clear: AFAIK there is no known comprehensive structure
theorem but also no known obstacles to derive such a theorem.
If we limit ourselfs to functions defined by linerar ODEs we can
effectively solve zero equivalence problem.
So as alternative solution we can do divisions only if we can prove
that divisor is non-zero. In most cases such proof could be done
by rather cheap floating point computation (but ATM Axiom have
very weak support for numeric computation of special functions).
I am not sure how well we want to support branch cuts. I belive
that in most practical cases functions are analytic, for example
sqrt(exp(%i*x)) is just exp(%i*x/2) (while branch cut interpretation
would produce artifical discontinuities). In other work "correctly"
handling branch cuts means solving hard problem giving result
which probably does not match with user expectations...
OTOH for numeric computation branch cuts seem to be accepted
solution. Using one definition for symbolic computations
and a different one for numeric computations breaks one
of fundamental expectations (namely, that evaluating functions
at a point is a homomorphizm).
\start
Date: Thu, 4 Jan 2007 10:00:42 -0500
From: Bill Page
To: Christian Aistleitner
Subject: RE: Using Aldor compiler from within Axiom on amd64
On Thursday, January 04, 2007 7:04 AM Christian Aistleitner wrote:
>
> I installed the binary Axiom+Aldor package from
> http://wiki.axiom-developer.org/Mirrors?go=/public/axiom-aldor
-20060621.tgz&it=Axiom+with+Aldor+binary
> according to the instructions on
> http://wiki.axiom-developer.org/AxiomBinaries
> on my gentoo amd64 system.
>
> Compiling the following short snippet (as test.as)
>
> #include "axiom"
>
> f():OutputForm == {
> import from Integer;
> outputForm 1;
> }
>
> within Axiom, gives no error. But when calling the function f after
> compilation, I get
>
> >> System error:
> Unknown bfd format
>
My guess is that the version of gcl from which Axiom+Aldor was
produced does not specify the appropriate gcc option (-m32 ?) to
ensure that the object file that is created from the Aldor lisp
output can be linked with the Axiom+Aldor binary.
> How can I get Axiom to run code that got compiled from
> within Axiom using the Aldor compiler?
>
I run Axiom with Aldor on my AMD64 system but I have compiled
both Axiom and Aldor from source on this system. If you absolutely
need a binary install, then I could create a tarball from this
system. Otherwise, I would recommend compiling Axiom from current
sources (I like the SourceForge svn build-improvements branch plus
the bug fixes from wh-sandbox branch.). You can then download the
amd64-bit version of Aldor from the link at the bottom of page:
http://wiki.axiom-developer.org/Aldor
Then you must follow the procedure at
http://wiki.axiom-developer.org/AldorForAxiom
to link Axiom with Aldor.
>
> Let me now give you more details about the setup:
>
> I know the downloaded file is a 32bit binary, but I have the
> appropriate 32bit libraries installed on my system:
>
Probably when the lisp generated by Aldor inside Axiom+Aldor is
compiled to object code, the object code defaults to a 64-bit
format that is incompatible with Axiom compiled for a 32-bit
system. It might be possible to get around this by specifying
different options for the compile. But I think you would be
happier running both Axiom and Aldor in full 64-bit mode.
\start
Date: Thu, 04 Jan 2007 16:10:38 +0100
From: Ralf Hemmecke
To: Franz Lehner
Subject: Re: How to do generic sum using aldor?
>> Since you want to work with Axiom, I guess you are right here.
> well, there is also axiom-math and axiom-mail ... anyways the people who
> answer seem to be the same:)
Right. There are not so many people anyway. And your question is not
only related to Math but it goes a bit deeper.
>> I currently rather rely on what is provided in LibAldor+LibAlgebra and
>> don't take things from LibAxiom, but that is personal taste.
> I wasn't aware that this is possible.
> Using #include "aldor" and #include "algebra" compiles but won't run:
> (1) -> sum [1,2,3]
>
> >> System error:
> AxiomXL file "sal_list" is missing!
>
> how can one mix axiom and libaldor?
I don't mix. You misunderstood. I for my taste find the libraries coming
with Aldor cleaner. And even though they have much less functionality,
it is sufficient for me. Sooner or later the Axiom library has to be
redesigned anyway, because the files should become literate documents
and all mis-design should go away. But that is a lot of work and
certainly not finished tomorrow.
Anyway, you have to use
#include "axiom"
if you want to use your things inside an Axiom session (which is not
primarily my goal).
>> Yep. But sorry to say: Axiom is weak in that respect (at least to my
>> knowledge).
> ok, at least this is an answer and I shall not try further.
Well, somebody should make Generator available in Axiom. ;-)
Actually, making Generator available is easy, but still that is not
enough. Axiom does not allow a Generator in a for expression so
g: Generator X := someAldorFunctionThatReturnsAGenerator()
for x in g repeat doSomething(x)
won't work. One can even work around a little as has been demonstrated
by Martin Rubey...
http://sourceforge.net/mailarchive/message.php?msg_id=37824208
Look into
svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/trunk
directory combinat/src/axiom-compatibility/axcompat*.as.nw
in order to see how Generator is made available.
In fact Aldor-Combinat is developed on libaldor+libalgebra, but by this
files in "axiom-compatibility" we provide some wrapper function to make
(nearly) the same code also compiling with libaxiom and thus available
in Axiom.
> Thus my "SumPackage" includes also
>
> sum ( ll: Stream R) : R == {
> import from StreamFunctions2(R,R);
> last complete scan(0,+, ll);
> }
>
> Is it really true that StreamFunctions2 must explicitly be imported?
StreamFunctions2 is a package. How else would the compiler find out that
you want to use a function from that package?
> The "last complete scan" makes me worry if the stream is really long
> and all intermediate results are stored; or is it optimized away by the
> compiler?
I don't think the compiler can optimize that away.
But in StreamAggregate you also find the exports
frst: % -> S
++ frst(s) returns the first element of stream s.
++ Caution: this function should only be called after a
\spad{empty?} test
++ has been made since there no error check.
rst: % -> %
++ rst(s) returns a pointer to the next node of stream s.
++ Caution: this function should only be called after a
\spad{empty?} test
++ has been made since there no error check.
There is also first and rest, but don't ask me which one you should use,
I have no idea.
> I rather would like the for loop but do not know where to import it from.
> greping the source files is not really helpful in this case ...
Use a while loop a la...
s: R := 0;
while not empty? ll repeat {
s := s + first ll;
ll := rest ll;
}
\start
Date: Fri, 5 Jan 2007 14:59:04 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Complex argument and mapleok
I have checked the impact of commplex argument patch on mapleok.
AFAICS the patch fixed 11 results. In one case previously correct
result changed to a wrong one. A few cases the results changed, but
both old and new result is wrong.
In general, we get a lot of wrong results in mapleok. The main reasons
are:
- our indefinite integrals have spurious singularities (the argument
patch eliminated some of them)
- we miss divergence of the integral (no wonder, since most integrals
use "noPole" option)
- we miss imaginary part. Many integrands have arguments outside
"real" domain and (at least in branch cut interpretation) have
complex values (sometimes arguments are on branch cuts). ATM
Axiom discards (if present) imaginary part of the result.
Also, the results look too complicated (at least in some cases I know
that there is simpler answer).
\start
Date: Fri, 05 Jan 2007 18:05:33 +0100
From: Ralf Hemmecke
To: list
Subject: executables under lib?
Hello,
I wanted to make Axiom available for all users of a Linux computer.
So I gave read and cd permission to every directory and read permission
to every file. Furthermore I made the files under axiom/mnt/linux/bin
executable for all.
However, as I learned now, that's not enough. There are executable files
under axiom/mnt/linux/lib.
Should I have expected that?
Ralf
/bin/sh: line 1: /zvol/axiom/axiom/mnt/linux/lib/session: Permission denied
/bin/sh: line 1: exec: /zvol/axiom/axiom/mnt/linux/lib/session: cannot
execute: Success
/bin/sh: line 1: /zvol/axiom/axiom/mnt/linux/lib/viewman: Permission denied
/bin/sh: line 1: exec: /zvol/axiom/axiom/mnt/linux/lib/viewman: cannot
execute: Success
\start
Date: 05 Jan 2007 18:05:53 +0100
From: Francois Maltey
To: list
Subject: Re: Zero divisors in Expression Integer
Waldek Hebisch writes:
[....]
> There is an extra difficulty: traditional numerical definitions
> of elementary functions have branch cuts. Branch cuts means
> that we no longer have analytic functions and we may get
> zero divisors even if algebraic approach would produce unique
> answer.
> Branch cuts turn decidable problem into undecidable one:
> I am not sure how well we want to support branch cuts. I belive
> that in most practical cases functions are analytic, for example
> sqrt(exp(%i*x)) is just exp(%i*x/2) (while branch cut interpretation
> would produce artifical discontinuities).
> In other work "correctly"
> handling branch cuts means solving hard problem giving result
> which probably does not match with user expectations...
> OTOH for numeric computation branch cuts seem to be accepted
> solution. Using one definition for symbolic computations
> and a different one for numeric computations breaks one
> of fundamental expectations (namely, that evaluating functions
> at a point is a homomorphizm).
I find very important this last point of view.
I try to use and to teach almost(?) the same mathematics with a pencil
and with a computer algebra system to my students.
A lot of formula about sqrt are right because there are the usual
branch cuts. Without theses branch cuts I fear we can write
-1 = 1^(1/2) = 1 and the equal isn't so associative.
I think the map notion has priority over branch cut.
For real numbers sqrt (x^2) = abs x is an universal equality
because sqrt is a map.
When we prefer to write sqrt (x^2) = x we loose the common sens of
mathematics and all the map abilities.
I give this exercice to my students.
Solve in x for a real number a the equation a (a-1) x = a
(or an other equation as this one)
With an algebra point of view we get x = 1/(a-1).
Standard mathematics prefers : a=0 => every x is solution.
a=1 => there is no solution
=> x = 1 / (a-1)
0/0 is undefined, even in a/a when a=0
I prefer a CAS which respect (almost) all mathematics by default.
When the question is undecidable or isn't coded an option
as << NoPole >> prevents the user to be prudent.
The topic of the #285 bug is almost the same.
In the elemntry package I test I only simplify by default exp (log z) = z,
not log (exp z) = z.
But in a rewrite? package I'll add a rewrite rule as
rewrite (log (exp z), logExp) which gives z.
\start
Date: Fri, 05 Jan 2007 13:32:22 -0500
From: William Sit
To: list
Subject: Disgruntled Debian Developers Delay Etch
The following may be contraversial but their experience may
be relevant to Axiom Foundation. Perhaps we can avoid what
Jaspert predicted, and please do not start any discussions
:-).
(This is "old" news, so may be it has been posted already,
or the situation has changed.)
Disgruntled Debian Developers Delay Etch
Debian GNU/Linux 4.0, code-named Etch, had been due to
arrive by Dec. 4, 2006, but it's been delayed because some
developers have deliberately slowed down their work.
Full article:
http://www.linux-watch.com/news/NS3128387759.html
\start
Date: Fri, 5 Jan 2007 14:19:56 -0500
From: Bill Page
To: William Sit
Subject: RE: Disgruntled Debian Developers Delay Etch
On January 5, 2007 1:32 PM William Sit wrote:
>
> The following may be contraversial but their experience may
> be relevant to Axiom Foundation. Perhaps we can avoid what
> Jaspert predicted, and please do not start any discussions
> :-).
> ...
> Full article:
> http://www.linux-watch.com/news/NS3128387759.html
>
Of course I wouldn't want to waste time discussing this :-) but
it might be relevant to note that the Axiom Foundation has not
yet paid anyone anything for working on Axiom. The only announced
initiative is to pay small "bounties" to encourage/reward Axiom
developers.
http://wiki.axiom-developer.org/AxiomFoundation
At the present time it has assets of about $500, entirely due to
donations, which seem to arrive at the rate of about $50 every
6 months or so ... So it seems that we can only "wish" that we
had the problems the Debian has. :-)
\start
Date: Fri, 05 Jan 2007 22:38:09 -0800
From: Arthur Ralfs
To: list
Subject: MathML package
Below is a package for producing presentation MathML. It's my first attempt
and based on Robert Sutor's TeXFomat domain. It's not finished but I would
particularly appreciate if somebody else would be interested in testing
it and
letting me know what doesn't work.
For now I have three exposed functions: coerce, coerceS and coerceL.
So after compiling and then entering some Axiom command, say x**2,
type
coerce(%)
this produces the MathML string as Axiom formats things for output
coerceS(%)
this also outputs with an initial attempt at formatting based on the
structure of the MathML, so take this and paste it into a suitable xml
file and open it in Firefox. If you paste this into emacs in nxml-mode
and indent-according-to-mode then it is supposed to be more
agreeable for human perusal.
coerceL(%)
this outputs the MathML string as one long line, more suitable for dom
insertion behind the scenes by javascript
I do intend, before I'm finished, to put this into the requisite pamphlet
style with more detailed documentation. I also have plans to start soon
on a content MathML package.
--Copyright (c) 1991-2002, The Numerical ALgorithms Group Ltd.
--All rights reserved.
--
--Redistribution and use in source and binary forms, with or without
--modification, are permitted provided that the following conditions are
--met:
--
-- - Redistributions of source code must retain the above copyright
-- notice, this list of conditions and the following disclaimer.
--
-- - Redistributions in binary form must reproduce the above copyright
-- notice, this list of conditions and the following disclaimer in
-- the documentation and/or other materials provided with the
-- distribution.
--
-- - Neither the name of The Numerical ALgorithms Group Ltd. nor the
-- names of its contributors may be used to endorse or promote products
-- derived from this software without specific prior written
permission.
--
--THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
--IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
--TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
--PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
--OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
--EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
--PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
--PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
--LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
--NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
--SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
)abbrev domain MMLFORM MathMLFormat
++ Author: Arthur C. Ralfs
++ Date: January 2007
++ This package is based on the TeXFormat domain by Robert S. Sutor
++ without which I wouldn't have known where to start.
MathMLFormat(): public == private where
E ==> OutputForm
I ==> Integer
L ==> List
S ==> String
US ==> UniversalSegment(Integer)
public == SetCategory with
coerce: E -> S
++ coerceS(o) changes o in the standard output format to MathML
++ format.
coerceS: E -> S
++ coerceS(o) changes o in the standard output format to MathML
++ format and displays formatted result.
coerceL: E -> S
++ coerceS(o) changes o in the standard output format to MathML
++ format and displays result as one long string.
private == add
import OutputForm
import Character
import Integer
import List OutputForm
import List String
-- local variables declarations and definitions
expr: E
prec,opPrec: I
str: S
blank : S := " \ "
maxPrec : I := 1000000
minPrec : I := 0
unaryOps : L S := ["-","^"]$(L S)
unaryPrecs : L I := [700,260]$(L I)
-- the precedence of / in the following is relatively low because
-- the bar obviates the need for parentheses.
binaryOps : L S := ["+->","|","**","/","<",">","=","OVER"]$(L S)
binaryPrecs : L I := [0,0,900, 700,400,400,400, 700]$(L I)
naryOps : L S := ["-","+","*",blank,",",";"," ","ROW","",
" \cr ","&","</mtd></mtr><mtr><mtd>"]$(L S)
naryPrecs : L I := [700,700,800, 800,110,110, 0, 0, 0,
0, 0, 0]$(L I)
naryNGOps : L S := ["ROW","&"]$(L S)
plexOps : L S :=
["SIGMA","SIGMA2","PI","PI2","INTSIGN","INDEFINTEGRAL"]$(L S)
plexPrecs : L I := [ 700, 800, 700, 800 , 700,
700]$(L I)
specialOps : L S :=
["MATRIX","BRACKET","BRACE","CONCATB","VCONCAT", _
"AGGLST","CONCAT","OVERBAR","ROOT","SUB","TAG", _
"SUPERSUB","ZAG","AGGSET","SC","PAREN", _
"SEGMENT","QUOTE","theMap" ]
-- the next two lists provide translations for some strings for
-- which MML provides special macros.
specialStrings : L S :=
["cos", "cot", "csc", "log", "sec", "sin", "tan",
"cosh", "coth", "csch", "sech", "sinh", "tanh",
"acos","asin","atan","erf","...","$","infinity"]
specialStringsInMML : L S :=
["<mo>cos</mo>","<mo>cot</mo>","<mo>csc</mo>","<mo>log</mo>","<mo>sec</mo>","<mo>sin</mo>","<mo>tan</mo>",
"<mo>cosh</mo>","<mo>coth</mo>","<mo>csch</mo>","<mo>sech</mo>","<mo>sinh</mo>","<mo>tanh</mo>",
"<mo>arccos</mo>","<mo>arcsin</mo>","<mo>arctan</mo>","<mo>erf</mo>","<mo>…</mo>","<mo>$</mo>","<mo>∞</mo>"]
-- local function signatures
addBraces: S -> S
addBrackets: S -> S
displayElt: S -> Void
++ function for recursively displaying mathml nicely formatted
eltLimit: (S,I,S) -> I
++ demarcates end postion of mathml element with name:S starting at
++ position i:I in mathml string s:S and returns end of end tag as
++ i:I position in mathml string, i.e. find start and end of
++ substring: <name ...>...</name>
eltName: (I,S) -> S
++ find name of mathml element starting at position i:I in string s:S
exprex: E -> S
group: S -> S
formatBinary: (S,L E, I) -> S
formatFunction: (S,L E, I) -> S
formatMatrix: L E -> S
formatNary: (S,L E, I) -> S
formatNaryNoGroup: (S,L E, I) -> S
formatNullary: S -> S
formatPlex: (S,L E, I) -> S
formatSpecial: (S,L E, I) -> S
formatUnary: (S, E, I) -> S
formatMml: (E,I) -> S
newWithNum: I -> $
parenthesize: S -> S
precondition: E -> E
postcondition: S -> S
stringify: E -> S
tagEnd: (S,I,S) -> I
++ finds closing ">" of start or end tag for mathML element
ungroup: S -> S
-- public function definitions
coerce(expr : E): S ==
s : S := postcondition formatMml(precondition expr, minPrec)
s
coerceS(expr : E): S ==
s : S := postcondition formatMml(precondition expr, minPrec)
sayTeX$Lisp "<math xmlns=_"http://www.w3.org/1998/Math/MathML_"
mathsize=_"big_" display=_"block_">"
displayElt(s)
sayTeX$Lisp "</math>"
s
coerceL(expr : E): S ==
s : S := postcondition formatMml(precondition expr, minPrec)
sayTeX$Lisp "<math xmlns=_"http://www.w3.org/1998/Math/MathML_"
mathsize=_"big_" display=_"block_">"
sayTeX$Lisp s
sayTeX$Lisp "</math>"
s
-- local function definitions
displayElt(mathML:S): Void ==
-- Takes a string of syntactically complete mathML
-- and formats it for display.
-- sayTeX$Lisp "****displayElt1****"
-- sayTeX$Lisp mathML
enT:I -- marks end of tag, e.g. "<name>"
enE:I -- marks end of element, e.g. "<name> ... </name>"
end:I -- marks end of mathML string
u:US
end := #mathML
length:I := 60
-- sayTeX$Lisp "****displayElt1.1****"
name:S := eltName(1,mathML)
-- sayTeX$Lisp name
-- sayTeX$Lisp concat("****displayElt1.2****",name)
enE := eltLimit(name,2+#name,mathML)
-- sayTeX$Lisp "****displayElt2****"
if enE < length then
-- sayTeX$Lisp "****displayElt3****"
u := segment(1,enE)$US
sayTeX$Lisp mathML.u
else
-- sayTeX$Lisp "****displayElt4****"
enT := tagEnd(name,1,mathML)
u := segment(1,enT)$US
sayTeX$Lisp mathML.u
u := segment(enT+1,enE-#name-3)$US
displayElt(mathML.u)
u := segment(enE-#name-2,enE)$US
sayTeX$Lisp mathML.u
if end > enE then
-- sayTeX$Lisp "****displayElt5****"
u := segment(enE+1,end)$US
displayElt(mathML.u)
void()$Void
eltName(pos:I,mathML:S): S ==
-- Assuming pos is the position of "<" for a start tag of a mathML
-- element finds and returns the element's name.
i:I := pos+1
--sayTeX$Lisp "eltName:mathmML string: "mathML
while member?(mathML.i,lowerCase()$CharacterClass)$CharacterClass
repeat
i := i+1
u:US := segment(pos+1,i-1)
name:S := mathML.u
eltLimit(name:S,pos:I,mathML:S): I ==
-- Finds the end of a mathML element like "<name ...> ... </name>"
-- where pos is the position of the space after name in the start tag
-- although it could point to the closing ">". Returns the position
-- of the ">" in the end tag.
pI:I := pos
startI:I
endI:I
startS:S := concat ["<",name]
endS:S := concat ["</",name,">"]
level:I := 1
--sayTeX$Lisp "eltLimit: element name: "name
while (level > 0) repeat
startI := position(startS,mathML,pI)$String
endI := position(endS,mathML,pI)$String
if (startI = 0) then
level := level-1
--sayTeX$Lisp "****eltLimit 1******"
pI := tagEnd(name,endI,mathML)
else
if (startI < endI) then
level := level+1
pI := tagEnd(name,startI,mathML)
else
level := level-1
pI := tagEnd(name,endI,mathML)
pI
tagEnd(name:S,pos:I,mathML:S):I ==
-- Finds the closing ">" for either a start or end tag of a mathML
-- element, so the return value is the position of ">" in mathML.
pI:I := pos
while (mathML.pI ^= char ">") repeat
pI := pI+1
u:US := segment(pos,pI)$US
--sayTeX$Lisp "tagEnd: "mathML.u
pI
exprex(expr : E): S ==
-- This is an attempt to break down the expr into atoms, not
-- satisfactorily so far.
le : L E := expr pretend L E
-- le : L E := (first rest le) pretend L E
-- le : L E := (first rest le) pretend L E
s : S := stringify first le
-- if #le > 1 then
-- for a in rest le repeat
-- s := concat [s,"{",exprex first rest le,"}"]
-- s := exprex first rest le
ungroup(str: S): S ==
len : I := #str
len < 14 => str
lrow : S := "<mrow>"
rrow : S := "</mrow>"
-- drop leading and trailing mrows
u1 : US := segment(1,6)$US
u2 : US := segment(len-6,len)$US
if (str.u1 =$S lrow) and (str.u2 =$S rrow) then
u : US := segment(7,len-7)$US
str := str.u
str
postcondition(str: S): S ==
str := ungroup str
len : I := #str
plusminus : S := "<mo>+</mo><mo>-</mo>"
pos : I := position(plusminus,str,1)
if pos > 0 then
ustart:US := segment(1,pos-1)$US
uend:US := segment(pos+20,len)$US
str := concat [str.ustart,"<mo>-</mo>",str.uend]
if pos < len-18 then
str := postcondition(str)
str
stringify expr == (object2String$Lisp expr)@S
group str ==
concat ["<mrow>",str,"</mrow>"]
addBraces str ==
concat ["<mo>[</mo>",str,"<mo>}</mo>"]
addBrackets str ==
concat ["<mo>[</mo>",str,"<mo>]</mo>"]
parenthesize str ==
concat ["<mo>(</mo>",str,"<mo>)</mo>"]
precondition expr ==
outputTran$Lisp expr
formatSpecial(op : S, args : L E, prec : I) : S ==
arg : E
prescript : Boolean := false
op = "theMap" => "<mtext>theMap(...)</mtext>"
op = "AGGLST" =>
formatNary(",",args,prec)
op = "AGGSET" =>
formatNary(";",args,prec)
op = "TAG" =>
group concat [formatMml(first args,prec),
"<mo>→</mo>",
formatMml(second args,prec)]
op = "VCONCAT" =>
group concat("<mtable><mtr>",
concat(concat([concat("<mtd>",concat(formatMml(u,
minPrec),"</mtd>"))
for u in args]::L S),
"</mtr></mtable>"))
op = "CONCATB" =>
formatNary(" ",args,prec)
op = "CONCAT" =>
formatNary("",args,minPrec)
op = "QUOTE" =>
group concat("<mo>'</mo>",formatMml(first args, minPrec))
op = "BRACKET" =>
group addBrackets ungroup formatMml(first args, minPrec)
op = "BRACE" =>
group addBraces ungroup formatMml(first args, minPrec)
op = "PAREN" =>
group parenthesize ungroup formatMml(first args, minPrec)
op = "OVERBAR" =>
null args => ""
group concat ["<mover accent='true'><mrow>",formatMml(first
args,minPrec),"</mrow><mo stretchy='true'>‾</mo>"]
op = "ROOT" =>
null args => ""
tmp : S := group formatMml(first args, minPrec)
null rest args => concat ["<msqrt>",tmp,"</msqrt>"]
group concat
["<mroot><mrow>",formatMml(first rest args,
minPrec),"</mrow>",tmp,"</mroot>"]
op = "SEGMENT" =>
tmp : S := concat [formatMml(first args, minPrec),"<mo>..</mo>"]
group
null rest args => tmp
concat [tmp,formatMml(first rest args, minPrec)]
op = "SUB" =>
group concat ["<msub>",formatMml(first args, minPrec),
formatSpecial("AGGLST",rest args,minPrec),"</msub>"]
op = "SUPERSUB" =>
base:S := formatMml(first args, minPrec)
args := rest args
if #args = 1 then
"<msub><mrow>"base"</mrow><mrow>"formatMml(first args,
minPrec)"</mrow></msub>"
else if #args = 2 then
"<msubsup><mrow>"base"</mrow><mrow>"formatMml(first
args,minPrec)"</mrow><mrow>"formatMml(first rest args,
minPrec)"</mrow></msubsup>"
else if #args = 3 then
"<mmultiscripts><mrow>"base"</mrow><mrow>"formatMml(first
args,minPrec)"</mrow><mrow>"formatMml(first rest
args,minPrec)"</mrow><mprescripts/><mrow>"formatMml(first rest rest
args,minPrec)"</mrow><none/></mmultiscripts>"
else if #args = 4 then
"<mmultiscripts><mrow>"base"</mrow><mrow>"formatMml(first
args,minPrec)"</mrow><mrow>"formatMml(first rest
args,minPrec)"</mrow><mprescripts/><mrow>"formatMml(first rest rest
args,minPrec)"</mrow><mrow>"formatMml(first rest rest rest
args,minPrec)"</mrow></mmultiscripts>"
else
"<mtext>Problem with multiscript object</mtext>"
op = "SC" =>
-- need to handle indentation someday
null args => ""
tmp := formatNaryNoGroup("</mtd></mtr><mtr><mtd>", args, minPrec)
group concat ["<mtable><mtr><mtd>",tmp,"</mtd></mtr></mtable>"]
op = "MATRIX" => formatMatrix rest args
op = "ZAG" =>
concat [" \zag{",formatMml(first args, minPrec),"}{",
formatMml(first rest args,minPrec),"}"]
concat ["<mtext>not done yet for: ",op,"</mtext>"]
formatPlex(op : S, args : L E, prec : I) : S ==
hold : S
p : I := position(op,plexOps)
p < 1 => error "unknown plex op"
opPrec := plexPrecs.p
n : I := #args
(n ^= 2) and (n ^= 3) => error "wrong number of arguments for plex"
s : S :=
op = "SIGMA" => "<mo>∑</mo>"
op = "SIGMA2" => "<mo>∑</mo>"
op = "PI" => "<mo>∏</mo>"
op = "PI2" => "<mo>∏</mo>"
op = "INTSIGN" => "<mo>∫</mo>"
op = "INDEFINTEGRAL" => "<mo>∫</mo>"
"????"
hold := formatMml(first args,minPrec)
args := rest args
if op ^= "INDEFINTEGRAL" then
if hold ^= "" then
s := concat ["<munderover>",s,group hold]
else
s := concat ["<munderover>",s,group " "]
if not null rest args then
hold := formatMml(first args,minPrec)
if hold ^= "" then
s := concat [s,group hold,"</munderover>"]
else
s := concat [s,group " ","</munderover>"]
args := rest args
s := concat [s,formatMml(first args,minPrec)]
else
hold := group concat [hold,formatMml(first args,minPrec)]
s := concat [s,hold]
if opPrec < prec then s := parenthesize s
group s
formatMatrix(args : L E) : S ==
-- format for args is [[ROW ...],[ROW ...],[ROW ...]]
-- generate string for formatting columns (centered)
group addBrackets concat
["<mtable><mtr><mtd>",formatNaryNoGroup("</mtd></mtr><mtr><mtd>",args,minPrec),
"</mtd></mtr></mtable>"]
formatFunction(op : S, args : L E, prec : I) : S ==
group concat ["<mo>",op,"</mo>",parenthesize
formatNary(",",args,minPrec)]
formatNullary(op : S) ==
op = "NOTHING" => ""
group concat ["<mo>",op,"</mo><mo>(</mo><mo>)</mo>"]
formatUnary(op : S, arg : E, prec : I) ==
p : I := position(op,unaryOps)
p < 1 => error "unknown unary op"
opPrec := unaryPrecs.p
s : S := concat ["<mo>",op,"</mo>",formatMml(arg,opPrec)]
opPrec < prec => group parenthesize s
op = "-" => s
group s
formatBinary(op : S, args : L E, prec : I) : S ==
p : I := position(op,binaryOps)
p < 1 => error "unknown binary op"
opPrec := binaryPrecs.p
s1 : S := formatMml(first args, opPrec)
s2 : S := formatMml(first rest args, opPrec)
op :=
op = "|" => s := concat
["<mrow>",s1,"</mrow><mo>",op,"</mo><mrow>",s2,"</mrow>"]
op = "**" => s := concat
["<msup><mrow>",s1,"</mrow><mrow>",s2,"</mrow></msup>"]
op = "/" => s := concat
["<mfrac><mrow>",s1,"</mrow><mrow>",s2,"</mrow></mfrac>"]
op = "OVER" => s := concat
["<mfrac><mrow>",s1,"</mrow><mrow>",s2,"</mrow></mfrac>"]
op = "+->" => s := concat
["<mrow>",s1,"</mrow><mo>",op,"</mo><mrow>",s2,"</mrow>"]
s := concat
["<mrow>",s1,"</mrow><mo>",op,"</mo><mrow>",s2,"</mrow>"]
group
op = "OVER" => s
opPrec < prec => parenthesize s
s
formatNary(op : S, args : L E, prec : I) : S ==
group formatNaryNoGroup(op, args, prec)
formatNaryNoGroup(op : S, args : L E, prec : I) : S ==
null args => ""
p : I := position(op,naryOps)
p < 1 => error "unknown nary op"
op :=
op = "," => "<mo>,</mo>" --originally , \:
op = ";" => "<mo>;</mo>" --originally ; \: should figure
these out
op = "*" => "<mo>⁢</mo>"
op = " " => "<mspace width='0.5em'/>"
op = "ROW" => "</mtd><mtd>"
op = "+" => "<mo>+</mo>"
op = "-" => "<mo>-</mo>"
op
l : L S := nil
opPrec := naryPrecs.p
for a in args repeat
l := concat(op,concat(formatMml(a,opPrec),l)$L(S))$L(S)
s : S := concat reverse rest l
opPrec < prec => parenthesize s
s
formatMml(expr,prec) ==
i,len : Integer
intSplitLen : Integer := 20
ATOM(expr)$Lisp@Boolean =>
str := stringify expr
len := #str
-- this bit seems to deal with integers
FIXP$Lisp expr =>
i := expr pretend Integer
if (i < 0) or (i > 9)
then
group
nstr : String := ""
-- insert some blanks into the string, if too long
while ((len := #str) > intSplitLen) repeat
nstr := concat [nstr," ",
elt(str,segment(1,intSplitLen)$US)]
str := elt(str,segment(intSplitLen+1)$US)
empty? nstr => concat ["<mn>",str,"</mn>"]
nstr :=
empty? str => nstr
concat [nstr," ",str]
concat ["<mn>",elt(nstr,segment(2)$US),"</mn>"]
else str := concat ["<mn>",str,"</mn>"]
str = "%pi" => "<mi>π</mi>"
str = "%e" => "<mi>ⅇ</mi>"
str = "%i" => "<mi>ⅈ</mi>"
-- what sort of atom starts with %%? need an example
len > 1 and str.1 = char "%" and str.2 = char "%" =>
u : US := segment(3,len)$US
concat(concat("<mi>",str.u),"</mi>")
len > 0 and str.1 = char "%" => concat(concat("<mi>",str),"</mi>")
len > 1 and digit? str.1 => concat ["<mn>",str,"</mn>"] --
should handle floats
-- presumably this is a literal string
len > 0 and str.1 = char "_"" =>
concat(concat("<mtext>",str),"</mtext>")
len = 1 and str.1 = char " " => "{\ }"
(i := position(str,specialStrings)) > 0 =>
specialStringsInMML.i
(i := position(char " ",str)) > 0 =>
-- We want to preserve spacing, so use a roman font.
-- What's this for? Leave the \rm in for now so I can see
-- where it arises.
concat(concat("<mtext>\rm ",str),"</mtext>")
-- if we get to here does that mean it's a variable?
concat ["<mi>",str,"</mi>"]
l : L E := (expr pretend L E)
null l => blank
op : S := stringify first l
args : L E := rest l
nargs : I := #args
-- special cases
member?(op, specialOps) => formatSpecial(op,args,prec)
member?(op, plexOps) => formatPlex(op,args,prec)
-- nullary case
0 = nargs => formatNullary op
-- unary case
(1 = nargs) and member?(op, unaryOps) =>
formatUnary(op, first args, prec)
-- binary case
(2 = nargs) and member?(op, binaryOps) =>
formatBinary(op, args, prec)
-- nary case
member?(op,naryNGOps) => formatNaryNoGroup(op,args, prec)
member?(op,naryOps) => formatNary(op,args, prec)
op := formatMml(first l,minPrec)
formatFunction(op,args,prec)
\start
Date: Sat, 06 Jan 2007 01:45:09 -0500
From: William Sit
To: Bill Page
Subject: Re: Disgruntled Debian Developers Delay Etch
Bill Page wrote:
>So it seems that we can only "wish" that we had the problems the
Debian has. :-)
Maybe that is a blessing in disguise. I think the donations have been
dribbling in because people do not see how the awards can be helpful.
When the award is too small, it is not a meaningful recognition
(compared with the actual appreciation from users). When it is large
enough, there will be the Debian dilemma.
Managing small grants is never worth the trouble and their rewards
lie mainly as entries in resumes. If we can raise a substantial
amount (at least $100k), we can at least support some graduate
students. But from your report, that seems hopeless, and fund-raising
is also a very time-consuming endeavor.
\start
Date: Sat, 06 Jan 2007 15:25:18 +0100
From: Christian Aistleitner
To: Bill Page
Subject: Re: Using Aldor compiler from within Axiom on amd64
Hello,
On Thu, 04 Jan 2007 16:00:42 +0100, Page, Bill Bill Page
wrote:
> On Thursday, January 04, 2007 7:04 AM Christian Aistleitner wrote:
>>
>> I installed the binary Axiom+Aldor package from
>> http://wiki.axiom-developer.org/Mirrors?go=/public/axiom-aldor
> -20060621.tgz&it=Axiom+with+Aldor+binary
>> according to the instructions on
>> http://wiki.axiom-developer.org/AxiomBinaries
>> on my gentoo amd64 system.
>>
>> Compiling the following short snippet (as test.as)
>>
>> [...]
>> I get
>>
>> >> System error:
>> Unknown bfd format
>>
>
> My guess is that the version of gcl from which Axiom+Aldor was
> produced does not specify the appropriate gcc option (-m32 ?) to
> ensure that the object file that is created from the Aldor lisp
> output can be linked with the Axiom+Aldor binary.
oh, besides the aldor compiler, axiom also uses gcl to compile aldor
sources?
How can I pass options to the gcl call? (When stating “)co something” only
the Aldor options are shown, so I supposed calling Aldor would be the
whole story)
>> How can I get Axiom to run code that got compiled from
>> within Axiom using the Aldor compiler?
>>
>
> [...]
> Then you must follow the procedure at
>
> http://wiki.axiom-developer.org/AldorForAxiom
>
> to link Axiom with Aldor.
I tried to follow that guide, but ran into trouble already at step 5
“Update your axiom source code to patch 44”, as for a fresh install, of
course I could not “tla update”. I tried with the silver sources instead.
Building axiom aborted, and make complained about denied permission to
modify
/home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/bin/tex/.svn/entries
/home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/bin/tex/.svn/all-wcprops
/home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/bin/tex/.svn/prop-base/axiom.sty.svn-base
/home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/bin/tex/.svn/text-base/axiom.sty.svn-base
chmodding everything within /hemo/tmgisi/axiom64 to 777, make got past
this point but make did not proceed for more than 24-hours at:
make[3]: Entering directory
`/home/tmgisi/axiom64/axiom.silver/axiom/src/doc'
1 making /home/tmgisi/axiom64/axiom.silver/axiom/int/doc/axiom.bib from
/home/tmgisi/axiom64/axiom.silver/axiom/src/doc/axiom.bib.pamphlet
2 making
/home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/bin/tex/axiom.sty from
/home/tmgisi/axiom64/axiom.silver/axiom/src/doc/axiom.sty.pamphlet
3 making
/home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/doc/DeveloperNotes.dvi
from
/home/tmgisi/axiom64/axiom.silver/axiom/src/doc/DeveloperNotes.pamphlet
The root module <<*>> was not defined.
4 making /home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/doc/book.dvi
from /home/tmgisi/axiom64/axiom.silver/axiom/src/doc/book.pamphlet
4 making
/home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/doc/bookvol1.dvi from
/home/tmgisi/axiom64/axiom.silver/axiom/src/doc/bookvol1.pamphlet
So obviously, at step 5 of
http://wiki.axiom-developer.org/AldorForAxiom
I chose the wrong sources. Would the golden one be the correct one then?
\start
Date: Sat, 06 Jan 2007 16:21:54 +0100
From: Ralf Hemmecke
To: Christian Aistleitner
Subject: Re: Using Aldor compiler from within Axiom on amd64
Hallo Christian,
I cannot help with all, but maybe with some of the problems.
>>> Compiling the following short snippet (as test.as)
>>>
>>> [...]
>>> I get
>>>
>>> >> System error:
>>> Unknown bfd format
>>>
>>
>> My guess is that the version of gcl from which Axiom+Aldor was
>> produced does not specify the appropriate gcc option (-m32 ?) to
>> ensure that the object file that is created from the Aldor lisp
>> output can be linked with the Axiom+Aldor binary.
>
> oh, besides the aldor compiler, axiom also uses gcl to compile aldor
> sources?
Aldor is only called to produce .ao, .asy, and .lsp files. Axiom starts
gcl in a second pass to make an .o file out of .lsp.
[...]
>> Then you must follow the procedure at
>>
>> http://wiki.axiom-developer.org/AldorForAxiom
>>
>> to link Axiom with Aldor.
>
> I tried to follow that guide, but ran into trouble already at step 5
> =E2=80=9CUpdate your axiom source code to patch 44=E2=80=9D, as for a fresh install, of
> course I could not =E2=80=9Ctla update=E2=80=9D. I tried with the silver sources
> instead. Building axiom aborted, and make complained about denied
> permission to modify
> /home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/bin/tex/.svn/entries
> /home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/bin/tex/.svn/all-wcprops
> /home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/bin/tex/.svn/prop-base/axiom.sty.svn-base
>
> /home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/bin/tex/.svn/text-base/axiom.sty.svn-base
That is a bug that I fixed in revision 75 of branches/build-improvements
at sourceforge.
Makefile.pamphlet:
Removed the line
@cp -pr ${SRC}/scripts/* ${MNT}/${SYS}/bin
from the target "rootdirs".
scr/scripts/Makefile.pamphlet:
Replace the "all" target code by the following two targets.
all: ${OUT}/Makefile.pamphlet
-@mkdir -p ${OUT}/tex
${OUT}/Makefile.pamphlet:
@echo 1 making ${SRC}/scripts
cp -pr * ${OUT}
There is actually another change in src/doc/Makefile.pamphlet, but maybe
the two files above suffice.
Maybe it is easier to use svk instead of svn. svk does not put .svn
directories inside the checked out tree.
See http://axiom.risc.uni-linz.ac.at/mathaction/AxiomSilverBranch
> chmodding everything within /hemo/tmgisi/axiom64 to 777, make got past
> this point but make did not proceed for more than 24-hours at:
>
> make[3]: Entering directory
> `/home/tmgisi/axiom64/axiom.silver/axiom/src/doc'
> 1 making /home/tmgisi/axiom64/axiom.silver/axiom/int/doc/axiom.bib from
> /home/tmgisi/axiom64/axiom.silver/axiom/src/doc/axiom.bib.pamphlet
> 2 making
> /home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/bin/tex/axiom.sty from
> /home/tmgisi/axiom64/axiom.silver/axiom/src/doc/axiom.sty.pamphlet
> 3 making
> /home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/doc/DeveloperNotes.dvi
> from
> /home/tmgisi/axiom64/axiom.silver/axiom/src/doc/DeveloperNotes.pamphlet
> The root module <<*>> was not defined.
> 4 making /home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/doc/book.dvi
> from /home/tmgisi/axiom64/axiom.silver/axiom/src/doc/book.pamphlet
> 4 making
> /home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/doc/bookvol1.dvi from
> /home/tmgisi/axiom64/axiom.silver/axiom/src/doc/bookvol1.pamphlet
>
>
> So obviously, at step 5 of
> http://wiki.axiom-developer.org/AldorForAxiom
> I chose the wrong sources. Would the golden one be the correct one then?
At least I compiled axiom--main--1--patch-50 (which is the current Gold
version) exactly as described on
http://axiom.risc.uni-linz.ac.at/mathaction/AxiomSilverBranch (including
the compilation of libaxiom.al.
I haven't yet tried Silver.
\start
Date: 06 Jan 2007 17:53:38 +0100
From: Gabriel Dos Reis
To: Christian Aistleitner
Subject: Re: Using Aldor compiler from within Axiom on amd64
Christian Aistleitner writes:
[...]
| chmodding everything within /hemo/tmgisi/axiom64 to 777, make got past
| this point but make did not proceed for more than 24-hours at:
|
| make[3]: Entering directory
| `/home/tmgisi/axiom64/axiom.silver/axiom/src/doc'
| 1 making /home/tmgisi/axiom64/axiom.silver/axiom/int/doc/axiom.bib
| from
| /home/tmgisi/axiom64/axiom.silver/axiom/src/doc/axiom.bib.pamphlet
| 2 making
| /home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/bin/tex/axiom.sty
| from
| /home/tmgisi/axiom64/axiom.silver/axiom/src/doc/axiom.sty.pamphlet
| 3 making
| /home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/doc/DeveloperNotes.dvi
| from
| /home/tmgisi/axiom64/axiom.silver/axiom/src/doc/DeveloperNotes.pamphlet
| The root module <<*>> was not defined.
| 4 making
| /home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/doc/book.dvi from
| /home/tmgisi/axiom64/axiom.silver/axiom/src/doc/book.pamphlet
| 4 making
| /home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/doc/bookvol1.dvi
| from /home/tmgisi/axiom64/axiom.silver/axiom/src/doc/bookvol1.pamphlet
Just press the Enter key twice or more. (That was latex wanting
interaction with you because of faulty formatting commands).
That is a known issue that was fixed a while ago -- at least in the
build-improvements branch; I thought it was also fixed in the mainline.
\start
Date: Sat, 06 Jan 2007 18:03:56 +0100
From: Gregory Vanuxem
To: Arthur Ralfs
Subject: Re: MathML package
Le vendredi 05 janvier 2007 =E0 22:38 -0800, Arthur Ralfs a =E9crit :
> Below is a package for producing presentation MathML. It's my first attempt
> and based on Robert Sutor's TeXFomat domain. It's not finished but I would
> particularly appreciate if somebody else would be interested in testing
> it and
> letting me know what doesn't work.
Can you resend your package in an attachment please, my MUA reformats
long lines (same thing, apparently, in the mailing list archives).
\start
Date: Sat, 6 Jan 2007 19:39:42 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Re: Zero divisors in Expression Integer
Francois Maltey wrote:
> Waldek Hebisch writes:
>
> [....]
>
> > There is an extra difficulty: traditional numerical definitions
> > of elementary functions have branch cuts. Branch cuts means
> > that we no longer have analytic functions and we may get
> > zero divisors even if algebraic approach would produce unique
> > answer.
>
> > Branch cuts turn decidable problem into undecidable one:
>
> > I am not sure how well we want to support branch cuts. I belive
> > that in most practical cases functions are analytic, for example
> > sqrt(exp(%i*x)) is just exp(%i*x/2) (while branch cut interpretation
> > would produce artifical discontinuities).
>
> > In other work "correctly"
> > handling branch cuts means solving hard problem giving result
> > which probably does not match with user expectations...
>
> > OTOH for numeric computation branch cuts seem to be accepted
> > solution. Using one definition for symbolic computations
> > and a different one for numeric computations breaks one
> > of fundamental expectations (namely, that evaluating functions
> > at a point is a homomorphizm).
>
> I find very important this last point of view.
>
> I try to use and to teach almost(?) the same mathematics with a pencil
> and with a computer algebra system to my students.
>
I should probably clarify what I wrote. I want Axiom to produce
mathematically correct results. Since many algorithms used by
Axiom are valid only in algebraic setting corresponding packages
should use algebraic interpretation (otherwise we get wrong
results). To handle conventions used in calculus we need higher
level packages. Such packages may for example find out that
x is always positive, so abs(x) = x, or if x changes sign such
package must split computation into two cases, one when abs(x) = x
and the another one where abs(x) = -x, and then finally recombine
the results.
But the case analysis may get messy (after all the problem is
undecidable) and will have to give up (say return expression
unevaluated). My feeling is that when analysing branch cuts
we may give up pretty quickly without loosing much of the
usefull expressions. OTOH it may be usefull to provide special
versions of log (and friends) which do not have branch cuts
-- such versions are more usefull for complex analysis.
> A lot of formula about sqrt are right because there are the usual
> branch cuts. Without theses branch cuts I fear we can write
> -1 = 1^(1/2) = 1 and the equal isn't so associative.
>
No, algebraic approach requires irreducible polynomial.
x^2-1 = (x + 1)*(x - 1) is reducible. So at low level 1^(1/2) is
illegal. At higher level 1^(1/2) should be either rejected or
(better) rewriten as 1.
> I think the map notion has priority over branch cut.
> For real numbers sqrt (x^2) = abs x is an universal equality
> because sqrt is a map.
>
Yes, but once we allow abs we have zero divisors -- so no function
field can allow abs. Insted the higher level code must split the
expression into two branches (or delegate the work to a ring)
And I certainly do not want Axiom to belive that
sqrt((x+%i*y)^2) = abs (x+%i*y)
> When we prefer to write sqrt (x^2) = x we loose the common sens of
> mathematics and all the map abilities.
>
IIRC some complex analysis texbooks contain formulas with sqrt which
are invalid if sqrt has branch cuts.
> I give this exercice to my students.
> Solve in x for a real number a the equation a (a-1) x = a
> (or an other equation as this one)
> With an algebra point of view we get x = 1/(a-1).
>
> Standard mathematics prefers : a=0 => every x is solution.
> a=1 => there is no solution
> => x = 1 / (a-1)
>
> 0/0 is undefined, even in a/a when a=0
>
You have a point here (Axiom currently gives the first answer).
> I prefer a CAS which respect (almost) all mathematics by default.
>
This is impossible if you want to stay in a single domain.
For example, I freqently use the formula:
exp(x)-exp(y) = integrate(exp((1-s)*x)*(y-x)*exp(s*y), s=0..1)
valid when x and y are (no commuting) operators. This formula
would be ruined by usual simplifications of exponentials.
Working with differential field we want log(exp(x)) = x.
So really each Axiom domain must implement its on simplifications.
> When the question is undecidable or isn't coded an option
> as << NoPole >> prevents the user to be prudent.
> The topic of the #285 bug is almost the same.
>
> In the elemntry package I test I only simplify by default exp (log z) = z,
> not log (exp z) = z.
>
You are doing nice things with expressions. But have you thought
how your work fits into Axiom design? Note that if your domain contain
division and you fail to discover zero the you are likely to get wrong
results. So the approach "simplify only when valid" may work only if
you do not simplify fractions. And Axiom simplifies fractions when
working with expressions...
\start
Date: Sun, 07 Jan 2007 20:21:41 +0100
From: Christian Aistleitner
To: Gabriel Dos Reis
Subject: Re: Using Aldor compiler from within Axiom on amd64
Hello Gaby,
On Sat, 06 Jan 2007 17:53:38 +0100, Gabriel Dos Reis
Gabriel Dos Reis wrote:
> Christian Aistleitner writes:
>
> [...]
>
> | chmodding everything within /hemo/tmgisi/axiom64 to 777, make got past
> | this point but make did not proceed for more than 24-hours at:
> |
> | make[3]: Entering directory
> | `/home/tmgisi/axiom64/axiom.silver/axiom/src/doc'
> | 1 making /home/tmgisi/axiom64/axiom.silver/axiom/int/doc/axiom.bib
> | from
> | /home/tmgisi/axiom64/axiom.silver/axiom/src/doc/axiom.bib.pamphlet
> | 2 making
> | /home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/bin/tex/axiom.sty
> | from
> | /home/tmgisi/axiom64/axiom.silver/axiom/src/doc/axiom.sty.pamphlet
> | 3 making
> |
> /home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/doc/DeveloperNotes.dvi
> | from
> | /home/tmgisi/axiom64/axiom.silver/axiom/src/doc/DeveloperNotes.pamphlet
> | The root module <<*>> was not defined.
> | 4 making
> | /home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/doc/book.dvi from
> | /home/tmgisi/axiom64/axiom.silver/axiom/src/doc/book.pamphlet
> | 4 making
> | /home/tmgisi/axiom64/axiom.silver/axiom/mnt/linux/doc/bookvol1.dvi
> | from /home/tmgisi/axiom64/axiom.silver/axiom/src/doc/bookvol1.pamphlet
>
> Just press the Enter key twice or more. (That was latex wanting
> interaction with you because of faulty formatting commands).
thank you. I did not dare just to step over such issues, ...
However, just ignoring the problem *sigh* allowed me to compile Axiom.
Thank you.
\start
Date: Sun, 07 Jan 2007 20:24:58 +0100
From: Christian Aistleitner
To: Ralf Hemmecke
Subject: Re: Using Aldor compiler from within Axiom on amd64
Hello,
> [...]
> I haven't yet tried Silver.
with the other replies in this thread I managed to install both the
current silver and the current gold sources.
\start
Date: Thu, 11 Jan 2007 09:42:10 -0500
From: Bill Page
To: Camm Maguire
Subject: RE: [Gcl-devel] Re: error in ./configure when building gcl 2.6.7 onUbuntu
Camm,
On January 10, 2007 11:12 AM you wrote:
> ...
> export CVSROOT=:pserver:anonymous@cvs.sv.gnu.org:/sources/gcl
> cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre
>
> This is way past due for release. I am only waiting on a volunteer
> to test a windows-only read patch -- alas our heroic windows
> volunteer has resigned. If anyone here can help please let me
> know.
> ...
Both Gaby and I have successfully built Axiom on Windows from a
recent version of gcl-2.6.8pre. What is required in order to test
this "windows-only read patch"?
\start
Date: 11 Jan 2007 10:50:54 -0500
From: Camm Maguire
To: Bill Page
Subject: Re: [Gcl-devel] Re: error in ./configure when building gcl 2.6.7 onUbuntu
Greetings, and thanks so much!
Could you please try reverting:
cvs -z9 -q diff -u -r 1.14.4.1.2.2.2.4.6.1.6.1.4.2 -r 1.14.4.1.2.2.2.4.6.1.6.1.4.3 read.d
Index: read.d
===================================================================
RCS file: /cvsroot/gcl/gcl/o/read.d,v
retrieving revision 1.14.4.1.2.2.2.4.6.1.6.1.4.2
retrieving revision 1.14.4.1.2.2.2.4.6.1.6.1.4.3
diff -u -r1.14.4.1.2.2.2.4.6.1.6.1.4.2 -r1.14.4.1.2.2.2.4.6.1.6.1.4.3
--- read.d 7 Jun 2006 15:09:38 -0000 1.14.4.1.2.2.2.4.6.1.6.1.4.2
+++ read.d 16 Jun 2006 02:26:22 -0000 1.14.4.1.2.2.2.4.6.1.6.1.4.3
@@ -256,6 +256,7 @@
x = read_object(in);
vs_push(x);
+#ifndef _WIN32
while (listen_stream(in)) {
object c=read_char(in);
if (cat(c)!=cat_whitespace) {
@@ -263,7 +264,7 @@
break;
}
}
-
+#endif
if (sharp_eq_context_max > 0)
x = vs_head = patch_sharp(x);
Take care,
Bill Page writes:
> Camm,
>
> On January 10, 2007 11:12 AM you wrote:
> > ...
> > export CVSROOT=:pserver:anonymous@cvs.sv.gnu.org:/sources/gcl
> > cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre
> >
> > This is way past due for release. I am only waiting on a volunteer
> > to test a windows-only read patch -- alas our heroic windows
> > volunteer has resigned. If anyone here can help please let me
> > know.
> > ...
>
> Both Gaby and I have successfully built Axiom on Windows from a
> recent version of gcl-2.6.8pre. What is required in order to test
> this "windows-only read patch"?
\start
Date: Thu, 11 Jan 2007 14:42:30 -0500
From: Bill Page
To: Camm Maguire
Subject: windows-only read patch (was: error in ./configure when building gcl 2.6.7 onUbuntu)
Camm,
What are the symptoms of this change? What problem is it
intended to correct? How can I test it? Is it sufficient
if I can build Axiom on windows after this change?
Regards,
Bill Page.
> -----Original Message-----
>
> Greetings, and thanks so much!
>
> Could you please try reverting:
>
> cvs -z9 -q diff -u -r 1.14.4.1.2.2.2.4.6.1.6.1.4.2 -r
> 1.14.4.1.2.2.2.4.6.1.6.1.4.3 read.d
> Index: read.d
> ===================================================================
> RCS file: /cvsroot/gcl/gcl/o/read.d,v
> retrieving revision 1.14.4.1.2.2.2.4.6.1.6.1.4.2
> retrieving revision 1.14.4.1.2.2.2.4.6.1.6.1.4.3
> diff -u -r1.14.4.1.2.2.2.4.6.1.6.1.4.2 -r1.14.4.1.2.2.2.4.6.1.6.1.4.3
> --- read.d 7 Jun 2006 15:09:38 -0000
> 1.14.4.1.2.2.2.4.6.1.6.1.4.2
> +++ read.d 16 Jun 2006 02:26:22 -0000
> 1.14.4.1.2.2.2.4.6.1.6.1.4.3
> @@ -256,6 +256,7 @@
>
> x = read_object(in);
> vs_push(x);
> +#ifndef _WIN32
> while (listen_stream(in)) {
> object c=read_char(in);
> if (cat(c)!=cat_whitespace) {
> @@ -263,7 +264,7 @@
> break;
> }
> }
> -
> +#endif
> if (sharp_eq_context_max > 0)
> x = vs_head = patch_sharp(x);
>
> Take care,
>
>
>
> Bill Page writes:
>
> > Camm,
> >
> > On January 10, 2007 11:12 AM you wrote:
> > > ...
> > > export CVSROOT=:pserver:anonymous@cvs.sv.gnu.org:/sources/gcl
> > > cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre
> > >
> > > This is way past due for release. I am only waiting on a
> volunteer
> > > to test a windows-only read patch -- alas our heroic windows
> > > volunteer has resigned. If anyone here can help please let me
> > > know.
> > > ...
> >
> > Both Gaby and I have successfully built Axiom on Windows from a
> > recent version of gcl-2.6.8pre. What is required in order to test
> > this "windows-only read patch"?
\start
Date: 11 Jan 2007 15:15:28 -0500
From: Camm Maguire
To: Bill Page
Subject: Re: windows-only read patch (was: error in ./configure when building gcl 2.6.7 onUbuntu)
Cc: Vadim V. Zhytnikov
Greetings!
Bill Page writes:
> Camm,
>
> What are the symptoms of this change? What problem is it
> intended to correct? How can I test it? Is it sufficient
> if I can build Axiom on windows after this change?
>
The code is intended to fix read-char-no-hang, which had been broken
for a long time. This caused Mike Thomas some problem of which I do
not know the details, hence his ifdef patch with the comment:
revision 1.14.4.1.2.2.2.4.6.1.6.1.4.3
date: 2006-06-15 22:26:22 -0400; author: mjthomas; state: Exp; lines: +2 -1
Band aid fix to stop build failure on Windows.
----------------------------
Vadim found the discrepancy in testing maxima:
http://www.mail-archive.com/gcl-devel@gnu.org/msg01408.html
Ideally, I'd like to know that reverting the patch works for both of
you. I'd really be pleased if someone could try acl2 as well.
Alas, due to email chaos, I seem to be disconnected from Vadim.
> > -----Original Message-----
> >
> > Could you please try reverting:
> >
> > cvs -z9 -q diff -u -r 1.14.4.1.2.2.2.4.6.1.6.1.4.2 -r
> > 1.14.4.1.2.2.2.4.6.1.6.1.4.3 read.d
> > Index: read.d
> > ===================================================================
> > RCS file: /cvsroot/gcl/gcl/o/read.d,v
> > retrieving revision 1.14.4.1.2.2.2.4.6.1.6.1.4.2
> > retrieving revision 1.14.4.1.2.2.2.4.6.1.6.1.4.3
> > diff -u -r1.14.4.1.2.2.2.4.6.1.6.1.4.2 -r1.14.4.1.2.2.2.4.6.1.6.1.4.3
> > --- read.d 7 Jun 2006 15:09:38 -0000
> > 1.14.4.1.2.2.2.4.6.1.6.1.4.2
> > +++ read.d 16 Jun 2006 02:26:22 -0000
> > 1.14.4.1.2.2.2.4.6.1.6.1.4.3
> > @@ -256,6 +256,7 @@
> >
> > x = read_object(in);
> > vs_push(x);
> > +#ifndef _WIN32
> > while (listen_stream(in)) {
> > object c=read_char(in);
> > if (cat(c)!=cat_whitespace) {
> > @@ -263,7 +264,7 @@
> > break;
> > }
> > }
> > -
> > +#endif
> > if (sharp_eq_context_max > 0)
> > x = vs_head = patch_sharp(x);
> >
> > Take care,
> >
> >
> >
> > Bill Page writes:
> >
> > > Camm,
> > >
> > > On January 10, 2007 11:12 AM you wrote:
> > > > ...
> > > > export CVSROOT=:pserver:anonymous@cvs.sv.gnu.org:/sources/gcl
> > > > cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre
> > > >
> > > > This is way past due for release. I am only waiting on a
> > volunteer
> > > > to test a windows-only read patch -- alas our heroic windows
> > > > volunteer has resigned. If anyone here can help please let me
> > > > know.
> > > > ...
> > >
> > > Both Gaby and I have successfully built Axiom on Windows from a
> > > recent version of gcl-2.6.8pre. What is required in order to test
> > > this "windows-only read patch"?
\start
Date: Fri, 12 Jan 2007 21:41:01 +0300
From: Vadim V. Zhytnikov
To: Camm Maguire
Subject: Re: [Gcl-devel] Re: windows-only read patch (was: error in ./configure when building gcl 2.6.7 onUbuntu)
Camm Maguire writes:
> Greetings!
>
> Bill Page writes:
>
>> Camm,
>>
>> What are the symptoms of this change? What problem is it
>> intended to correct? How can I test it? Is it sufficient
>> if I can build Axiom on windows after this change?
>>
>
> The code is intended to fix read-char-no-hang, which had been broken
> for a long time. This caused Mike Thomas some problem of which I do
> not know the details, hence his ifdef patch with the comment:
>
> revision 1.14.4.1.2.2.2.4.6.1.6.1.4.3
> date: 2006-06-15 22:26:22 -0400; author: mjthomas; state: Exp; lines: +2 -1
> Band aid fix to stop build failure on Windows.
> ----------------------------
>
> Vadim found the discrepancy in testing maxima:
>
> http://www.mail-archive.com/gcl-devel@gnu.org/msg01408.html
>
> Ideally, I'd like to know that reverting the patch works for both of
> you. I'd really be pleased if someone could try acl2 as well.
Sorry, probably I've lost track of the topic.
I'm ready to test with Maxima on both Linux and Windows.
Would you please clarify which version of GCL should
be tested. GCL 2.6.8 CVS without aforementioned patch?
>
> Alas, due to email chaos, I seem to be disconnected from Vadim.
>
Please, try <vvzhyt@gmail.com>
\start
Date: Mon, 15 Jan 2007 02:46:49 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Infinite loop computing Laplace transform
I have looked at bug 101. At the end of LaplaceTransform.locallaplace
we have:
-- last chance option: try to use the fact that
-- laplace(f(t),t,s) = s laplace(g(t),t,s) - g(0) where dg/dt = f(t)
elem?(int := lfintegrate(f, t)) and (rint := retractIfCan int) case F =>
fint := rint :: F
-- to avoid infinite loops, we don't call laplace recursively
-- if the integral has no new logs and f is an algebraic function
empty?(logpart int) and algebraic?(f, t) => oplap(fint, tt, ss)
ss * locallaplace(fint, t, tt, s, ss) - eval(fint, tt = 0)
The recursion here is responsible for infinite loop when computing
laplace(log(z), z, w). Namely, at this point f = log(z). Integrating
we get z*log(z) - z. First part of locallaplace uses linearity
and recurses with f = z*log(z). Again first part factors out z and
recurses with f = log(z)...
ATM I am unable to find a function such that this fragment helps. OTOH
the fragment is quite likely to cause infinite recursion so I consider
disabling it.
\start
Date: 15 Jan 2007 18:55:17 -0600
From: Gabriel Dos Reis
To: list
Subject: PATCH to src/interp/ptrees.boot
There is a duplicate test for the data type used to implement
the abstract syntax trees found in src/interp/ptrees.boot.
This is a correction I would have liked to apply globally to
Axiom trunk, but the trunk has gone through several renamings,
mutations, redefinitions, changes of status, etc. so that I don't know
what is what at this moment. So, I'm committing to the
build-improvement branch only.
-- Gaby
2007-01-11 Gabriel Dos Reis Gabriel Dos Reis
* ptrees.boot.pamphlet (pfExpr?): Don't duplicate test for
Typing and Sequence. They are part of DeclPart.
*** ptrees.boot.pamphlet (revision 17763)
--- ptrees.boot.pamphlet (local)
*************** pfExpr? pf ==
*** 286,295 ****
pfPretend? pf or _
pfRestrict? pf or _
pfReturn? pf or _
- pfSequence? pf or _
pfTagged? pf or _
pfTuple? pf or _
- pfTyping? pf or _
pfWhere? pf or _
pfWith? pf
--- 286,293 ----
\start
Date: Tue, 16 Jan 2007 01:33:35 -0500
From: Tim Daly
To: Guy Steele
Subject: Mathematical Programming Languages with strong typing
I've been reviewing your documents on Fortress.
Have you seen Axiom (http://wiki.axiom-developer.org)?
It already has some of the parameterized types as well as
a very strong mathematical structure.
\start
Date: Tue, 16 Jan 2007 02:08:14 -0500
From: Tim Daly
To: Guy Steele
Subject: Parallelism in mathematical languages
One thought about parallelism is that you've implicitly
introduced a serial idea when you do computation by
a series of assignments. This seriously inhibits your
ability to think and program in parallel. Instead of
the serial assignment model of programming you might
consider thinking in terms of conditions on the initial and
final states of a computation.
Within a mathematical based language (e.g. Axiom)
it would be more natural and reasonable to introduce
parallelism by using PROVISOS..
A proviso is a set of conditions attached to a particular
equation. For instance, you often see in mathematical
textbooks statements of the form:
1/x provided x <> 0
A study I did shows that about 80% of all of the provisos
attached to mathematical statements in books can be written in
interval form. The above could be expressed as a statement
with two interval conditions
1/x provided ([-\infty < x < 0] or [0 > x > \infty])
These provisos are naturally added by operators (e.g. division)
Now this statement naturally breaks into two disjoint parts.
If you assume that this statement arises in the middle of a
mathematical computation you have a natural branch point
for parallel computations, the "left branch" computing under
the proviso
1/x provided [-\infty < x < 0]
and the "right branch" computing under the proviso
1/x provided [0 > x > \infty]
assuming further that another division occurs, perchance by y
we might find the left branch computation continued as
(1/x provided [-\infty < x < 0])/y provided
([-\infty < y < 0] or [0 > y > \infty])
which naturally branches again giving 4 disjoint paths for
the computation. Thus mathematical computation
under provisos creates natural parallel tree structures.
Combining branches on the tree involves two kinds of computation...
computing "with" provisos and computing "of" provisos.
Computing "with" provisos creates the branching structure above.
Computing "of" provisos involves combination within the provisos
portion so that we might find combinations like:
((foo(x) provided [3 < x < 4]) provided [3 < x < 4])
which trivially collapses into
(foo(x) provided [3 < x < 4])
While not interesting mathematically we have just managed to
combine two branches of the tree into a single branch, thus
creating a "join" condition using provisos. Computation "of"
provisos also introduces a natural place to generate program
proofs. The language of the proviso can be very logic based
yielding the ability to use ACL2 (Univ. of Texas work).
The whole idea is too large to fit into this margin but you can
see infer some interesting features.
* parallel computations arise naturally.
* branch cuts, poles, properties (e.g. entire, meromorphic) can be
expressed as provisos.
* computations carry assumptions and ranges of validity
* multi-valued answers (e.g. piecewise equations) are natural
* computational ranges are easily expressed (e.g. [minint <= x <= maxint])
I'm concerned that you're creating your own box by deciding to
follow the standard model of serial programming. Under the
assumption that this language is used for mathematics the proviso
model is much more natural and powerful.
\start
Date: 16 Jan 2007 16:57:16 -0600
From: Gabriel Dos Reis
To: Tim Daly
Subject: ncloopProcess
Where is ncloopProcess defined?
Brute force grep shows no match...
\start
Date: Wed, 17 Jan 2007 00:20:46 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: ncloopProcess
>
> Hi Tim,
>
> Where is ncloopProcess defined?
>
> Brute force grep shows no match...
>
Lisp tells me that ncloopProcess is undefined:
)lisp (fboundp '|ncloopProcess|)
Value = NIL
Grepping shows that ncloopProcess is only used in ncloopInclude0
which in turn is only used in ncloopInclude which is unused.
AFAICS this is part of "new" unfinished toplevel.
\start
Date: 16 Jan 2007 17:39:47 -0600
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: ncloopProcess
Waldek Hebisch writes:
| >
| > Hi Tim,
| >
| > Where is ncloopProcess defined?
| >
| > Brute force grep shows no match...
| >
|
| Lisp tells me that ncloopProcess is undefined:
|
| )lisp (fboundp '|ncloopProcess|)
|
| Value = NIL
|
| Grepping shows that ncloopProcess is only used in ncloopInclude0
| which in turn is only used in ncloopInclude which is unused.
Thanks for concurring.
I speculated, based on the missing definition, that ncloopInclude may
be not be used at the moment.
| AFAICS this is part of "new" unfinished toplevel.
OK, thanks.
We should probably have a list "open projects" consisting of
unfinished "new" parts.
\start
Date: 16 Jan 2007 20:18:01 -0600
From: Gabriel Dos Reis
To: Tim Daly
Subject: sayMessage
Tim --
The function sayMessage appears to be defined at least in two locations:
(1) src/interp/mark.boot
(2) src/interp/msgdb.boot
which one should be considered the "true" definition?
[ also, the perspective is having many definitions, overriding or not,
for same functions is seriously annoying when looking for
information. ]
\start
Date: Wed, 17 Jan 2007 04:22:16 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: sayMessage
>
> Tim --
>
> The function sayMessage appears to be defined at least in two locations:
>
> (1) src/interp/mark.boot
> (2) src/interp/msgdb.boot
>
> which one should be considered the "true" definition?
>
>
> [ also, the perspective is having many definitions, overriding or not,
> for same functions is seriously annoying when looking for
> information. ]
>
mark.boot is part of Axiom to Aldor translator. In normal use this
file (as all TRANOBJS) is not used. Before starting Axiom to Aldor
translatotion TRANOBJS are loaded and overwrite many compiler functions.
I personally do not like this design, but it is not clear if
alternatives are better. I considered:
- making a completly independent function hierarchy for translator
- adding global flag tested by relevant compiler functions
- using assignment to 'symbol-function'
- mixture of all above
First variant means significant code duplication. Second variant
means that individal compiler functions would be cluttered with extra
functionality which is unused during normal operation. Third
variant is a slight improvement compared to current situation
(would allow to restore normal operation when the translator
has finished), but ATM I am not sure if gains would justify
effort. Fourth variant IMHO would only add confusion due to
inconsistency.
\start
Date: Wed, 17 Jan 2007 09:42:45 +0100
From: Juergen Weiss
To: list
Subject: RE: ncloopProcess
As far as I know, the nc functions are from the "New Compiler",
which does not exist anymore. It should have replaced the old compiler,
which is the current SPAD compiler. This does not mean, that the
functions might be used somewhere :-(.
Regards
Juergen Weiss
Juergen Weiss | Universitaet Mainz, Zentrum fuer Datenverarbeitung,
Juergen Weiss| 55099 Mainz, Tel: +49(6131)39-26361, FAX:
+49(6131)39-26407
> -----Original Message-----
> From: axiom-developer-bounces+weiss=uni-mainz.de@nongnu.org
> On Behalf Of Gabriel Dos Reis
> Sent: Wednesday, January 17, 2007 12:40 AM
> To: Waldek Hebisch
> Cc: list
> Subject: Re: ncloopProcess
>
> Waldek Hebisch writes:
>
> | >
> | > Hi Tim,
> | >
> | > Where is ncloopProcess defined?
> | >
> | > Brute force grep shows no match...
> | >
> |
> | Lisp tells me that ncloopProcess is undefined:
> |
> | )lisp (fboundp '|ncloopProcess|)
> |
> | Value = NIL
> |
> | Grepping shows that ncloopProcess is only used in ncloopInclude0
> | which in turn is only used in ncloopInclude which is unused.
>
> Thanks for concurring.
>
> I speculated, based on the missing definition, that ncloopInclude may
> be not be used at the moment.
>
> | AFAICS this is part of "new" unfinished toplevel.
>
> OK, thanks.
>
> We should probably have a list "open projects" consisting of
> unfinished "new" parts.
\start
Date: 17 Jan 2007 05:23:00 -0600
From: Gabriel Dos Reis
To: Juergen Weiss
Subject: Re: ncloopProcess
Juergen Weiss writes:
| As far as I know, the nc functions are from the "New Compiler",
| which does not exist anymore. It should have replaced the old compiler,
| which is the current SPAD compiler. This does not mean, that the
| functions might be used somewhere :-(.
|
| Regards
Hi Juergen,
You said "which does not exist anymore". Did you mean it existed at
some point, but was removed? If yes, do you happen to remember what
the reasons were?
\start
Date: Wed, 17 Jan 2007 12:52:45 +0100
From: Juergen Weiss
To: Gabriel Dos Reis
Subject: RE: ncloopProcess
Hi,
I think, before 1990 someone wrote a new scratchpad compiler in
lisp. It seems that it was not better than the old one. So
the code was abandoned and the A#/Aldor compiler was developed
around 1990. Maybe Tim knows more details.
Regards
Juergen Weiss
Juergen Weiss | Universitaet Mainz, Zentrum fuer Datenverarbeitung,
Juergen Weiss| 55099 Mainz, Tel: +49(6131)39-26361, FAX:
+49(6131)39-26407
> -----Original Message-----
> From: Gabriel Dos Reis
> [mailto:Gabriel Dos Reis] On Behalf Of Gabriel Dos Reis
> Sent: Wednesday, January 17, 2007 12:23 PM
> To: Weiss, Juergen
> Cc: list
> Subject: Re: ncloopProcess
>
> Juergen Weiss writes:
>
> | As far as I know, the nc functions are from the "New Compiler",
> | which does not exist anymore. It should have replaced the
> old compiler,
> | which is the current SPAD compiler. This does not mean, that the
> | functions might be used somewhere :-(.
> |
> | Regards
>
> Hi Juergen,
>
> You said "which does not exist anymore". Did you mean it existed at
> some point, but was removed? If yes, do you happen to remember what
> the reasons were?
\start
Date: Tue, 16 Jan 2007 16:06:49 -0500
From: Guy Steele
To: Tim Daly
Subject: Re: Parallelism in mathematical languages
Thanks for your comments about Fortress and Axiom.
I have seen older documents about Axiom, and you
have given me some new ideas to think about.
Yours,
Guy Steele
On Jan 16, 2007, at 2:08 AM, Tim Daly wrote:
> One thought about parallelism is that you've implicitly
> introduced a serial idea when you do computation by
> a series of assignments. This seriously inhibits your
> ability to think and program in parallel. Instead of
> the serial assignment model of programming you might
> consider thinking in terms of conditions on the initial and
> final states of a computation.
>
> Within a mathematical based language (e.g. Axiom)
> it would be more natural and reasonable to introduce
> parallelism by using PROVISOS..
>
> A proviso is a set of conditions attached to a particular
> equation. For instance, you often see in mathematical
> textbooks statements of the form:
>
> 1/x provided x <> 0
>
> A study I did shows that about 80% of all of the provisos
> attached to mathematical statements in books can be written in
> interval form. The above could be expressed as a statement
> with two interval conditions
>
> 1/x provided ([-\infty < x < 0] or [0 > x > \infty])
>
> These provisos are naturally added by operators (e.g. division)
>
> Now this statement naturally breaks into two disjoint parts.
> If you assume that this statement arises in the middle of a
> mathematical computation you have a natural branch point
> for parallel computations, the "left branch" computing under
> the proviso
>
> 1/x provided [-\infty < x < 0]
>
> and the "right branch" computing under the proviso
>
> 1/x provided [0 > x > \infty]
>
> assuming further that another division occurs, perchance by y
> we might find the left branch computation continued as
>
> (1/x provided [-\infty < x < 0])/y provided
> ([-\infty < y < 0] or [0 > y > \infty])
>
> which naturally branches again giving 4 disjoint paths for
> the computation. Thus mathematical computation
> under provisos creates natural parallel tree structures.
>
> Combining branches on the tree involves two kinds of computation...
> computing "with" provisos and computing "of" provisos.
>
> Computing "with" provisos creates the branching structure above.
> Computing "of" provisos involves combination within the provisos
> portion so that we might find combinations like:
>
> ((foo(x) provided [3 < x < 4]) provided [3 < x < 4])
>
> which trivially collapses into
>
> (foo(x) provided [3 < x < 4])
>
> While not interesting mathematically we have just managed to
> combine two branches of the tree into a single branch, thus
> creating a "join" condition using provisos. Computation "of"
> provisos also introduces a natural place to generate program
> proofs. The language of the proviso can be very logic based
> yielding the ability to use ACL2 (Univ. of Texas work).
>
>
>
> The whole idea is too large to fit into this margin but you can
> see infer some interesting features.
>
> * parallel computations arise naturally.
> * branch cuts, poles, properties (e.g. entire, meromorphic) can be
> expressed as provisos.
> * computations carry assumptions and ranges of validity
> * multi-valued answers (e.g. piecewise equations) are natural
> * computational ranges are easily expressed (e.g. [minint <= x <=
> maxint])
>
>
> I'm concerned that you're creating your own box by deciding to
> follow the standard model of serial programming. Under the
> assumption that this language is used for mathematics the proviso
> model is much more natural and powerful.
\start
Date: Wed, 17 Jan 2007 16:23:06 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Bug 215: sin asin(7.0::COMPLEX FLOAT)
The problem here is that sin asin(7.0::COMPLEX FLOAT) give something
close to -7. This is due to wrong bunch cuts during evaliation.
Namely in trigcat we have:
asin x == atan(x/sqrt(1-x**2))
this formula for asin has wrong branch cuts. When x is real and bigger
then 1 sqrt(1-x**2) is imaginary with positive imaginary part. So
x/sqrt(1-x**2) is imaginary with _negative_ imaginary part. atan has
branch cut on %i*[-1, %minusInfinity], with jump discontinuity when
real part goes to 0 trough positve values. This discontinuity means
that values of asin are wrong (of opposite sign) for big real x.
There is an easy workaround, put:
asin x == -atan(-x/sqrt(1-x**2))
However, the problem with asin is just one special case. We
would like to support many multivalued special functions (which in
numerical version require branch cuts). Tracking that we get
"correct" values on cuts may well take significant portion of
effert to implements those functions. OTOH computing with
values on branch cuts does not seem very useful. So I am tempted
to declare that arguments branch cuts are errors (like divison
by 0).
\start
Date: 17 Jan 2007 09:53:32 -0600
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Bug 215: sin asin(7.0::COMPLEX FLOAT)
Waldek Hebisch writes:
| The problem here is that sin asin(7.0::COMPLEX FLOAT) give something
| close to -7. This is due to wrong bunch cuts during evaliation.
| Namely in trigcat we have:
|
| asin x == atan(x/sqrt(1-x**2))
|
| this formula for asin has wrong branch cuts. When x is real and bigger
| then 1 sqrt(1-x**2) is imaginary with positive imaginary part. So
| x/sqrt(1-x**2) is imaginary with _negative_ imaginary part. atan has
| branch cut on %i*[-1, %minusInfinity], with jump discontinuity when
| real part goes to 0 trough positve values. This discontinuity means
| that values of asin are wrong (of opposite sign) for big real x.
|
| There is an easy workaround, put:
|
| asin x == -atan(-x/sqrt(1-x**2))
|
| However, the problem with asin is just one special case. We
| would like to support many multivalued special functions (which in
| numerical version require branch cuts). Tracking that we get
| "correct" values on cuts may well take significant portion of
| effert to implements those functions. OTOH computing with
| values on branch cuts does not seem very useful. So I am tempted
| to declare that arguments branch cuts are errors (like divison
| by 0).
I'm concerned with that approach.
After all, this is a mathematical computational platform. If we go
that way, how else can we expect other people to take branch cuts
seriously?
\start
Date: Wed, 17 Jan 2007 16:54:19 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Re: Bug 215: sin asin(7.0::COMPLEX FLOAT)
I wrote:
> There is an easy workaround, put:
>
> asin x == -atan(-x/sqrt(1-x**2))
>
After further examination I have found that this does not work
(appearantly I was using different version for machine test, and
analysis shows that the formula above is wrong). Actually,
now I am convinced that there is no simple "real" formula giving
correct branch cuts. Official Lisp formula for asin is
asin x == -%i*log(%i*x+sqrt(1-x^2))
The Lisp formula stays away from branch cuts of logarithm, and only
branch cut of sqrt matters (and defines brunch cuts of asin).
So, to get correct asin we need a real function which contains
-%i*log as the last step of computation. However, our only
primitive of this sort is atan and contains spurious branch cut.
So we probably need to provide a complex asin in Complex (or throw
error for computations on branch cuts). We could also try to use
complex formula in TrigonometricFunctionCategory, but I am affraid
that Axiom assumes in too many places that real functions of
real arguments are computed in "real way", we could easily get
wrong results (starting from enexpected complex expressions to
plain wrong).
\start
Date: 17 Jan 2007 10:00:06 -0600
From: Gabriel Dos Reis
To: Tim Daly
Subject: interpreter and with-expression
The interpreter (in particular pf2Sex) does not handle category
definitions (with-expression). Is that by design or an "unfinished" part?
In case it is by design, what is the rationale?
\start
Date: Wed, 17 Jan 2007 10:13:17 -0600
From: Tim Daly
To: Juergen Weiss, Gabriel Dos Reis
Subject: new compiler, ncloopProcess
Scratchpad was a research project used by many people in
different ways. As such it was always a "work in progress".
Several people worked on "the new compiler" over time.
The original plan was to have the new compiler exist in
the lisp system. Stephen Watt decided to implement it in C
as a standalone program and this became the final version.
However there were many "new compilers" in lisp both before
and during that effort. The early compilers tried new ideas
and the later compilers maintained compatibility with aldor.
The "new compiler" (remember that the word "new" basically
meant "this week's changes") was carried on in parallel in
both C (asharp,aldor) and lisp. We had to keep the syntax
and semantics as close as possible. The "old compiler" and
the "new compiler" existed at the same time in the lisp
system. (Note that "the old compiler" refers to last week's
version and "the new compiler" was this week's version).
This was also true with the "old boot parser" and "the new
boot parser" and the interpreter, etc. Everything was always
changing.
IBM hit a rough financial patch and Scratchpad was turned
into a "product" and sold to NAG. The process was not very
clean as we had very little time. Plus we had other tasks
such as adding the fortran interface so we could talk to
the NAG library, additional code changes to handle Arthur
Norman's CCL and a huge documentation effort.
Thus the code you see has never had a "proper" cleanup.
We need to select and collect the live code, understand it,
document it, and restructure it so it can be maintained.
Thus it is hardly a surprise to find duplicate functions
with different definitions. Careful study is needed to
decide which one is used at what time (since some can be
autoloaded, overriding the existing definition).
Rather than taking each function individually I've been
walking the spanning code tree and dragging the functions
into bookvol5.pamphlet which is intended to be the new
interpreter. Someone needs to do something similar with
the compiler. This "garbage collection" approach will
prove that any extra functions must be unused and can be
discarded.
Also of note with regard to ncloopProcess.... There are
several "top level"s of the Axiom system which are not
apparent. There are functions which start the boot parser,
compiler, or interpreter in different modes to do different
things. This is not documented and not apparent. It was
intended for use by the developers of axiom so they could
debug their programs. Some of these ended up abandoned.
\start
Date: Wed, 17 Jan 2007 10:21:11 -0600
From: Tim Daly
To: Gabriel Dos Reis
Subject: interpreter and with-expression
> The interpreter (in particular pf2Sex) does not handle category
> definitions (with-expression). Is that by design or an "unfinished part"
I'm not sure that it is possible to create categories at the
interpreter level. Well, in theory it is since a category is
simply a lisp expression, but in practice I don't think it works.
Categories are a compile-time concept.
\start
Date: Wed, 17 Jan 2007 10:33:28 -0600 (CST)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: interpreter and with-expression
On Wed, 17 Jan 2007 Tim Daly wrote:
| > The interpreter (in particular pf2Sex) does not handle category
| > definitions (with-expression). Is that by design or an "unfinished part"
|
| I'm not sure that it is possible to create categories at the
| interpreter level. Well, in theory it is since a category is
| simply a lisp expression, but in practice I don't think it works.
| Categories are a compile-time concept.
I'm unsure about the meaning you give to "compile-time" here.
Types are compile-time concepts too. Yet, the interpreter has no
problem handing
Foo == Record(f: Integer, b: Boolean)
or
Bar := Record(f: Integer, b: Boolean)
Furthermore within an axiom session, it is possible to )compile a file
and have the result available in the working frame.
I tripped over this while working on new packages for Axiom, and
it really is confusing. I would like to know whether there are
deep reasons for this, or whether it is because it was not
finished.
\start
Date: Wed, 17 Jan 2007 17:35:30 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Bug 215: sin asin(7.0::COMPLEX FLOAT)
Gabriel Dos Reis wrote:
> Waldek Hebisch writes:
> | However, the problem with asin is just one special case. We
> | would like to support many multivalued special functions (which in
> | numerical version require branch cuts). Tracking that we get
> | "correct" values on cuts may well take significant portion of
> | effert to implements those functions. OTOH computing with
> | values on branch cuts does not seem very useful. So I am tempted
> | to declare that arguments branch cuts are errors (like divison
> | by 0).
>
> I'm concerned with that approach.
>
> After all, this is a mathematical computational platform. If we go
> that way, how else can we expect other people to take branch cuts
> seriously?
>
1)
What can be more serious than signaling error?
2)
I am mathematician and I do not "take branch cuts seriously".
Serious math works with arbitrary branches, multivalued functions
or Riemennian surfaces. Branch cuts are an artifical convention
which pretends that multivalued functions can be used naively in
numerical computations. In some sense it is an ideal field for
standarisation: many choices are arbitrary, but for effective
shortcut communication everybody should use the same choices.
However, standarizing branch cuts produces a formal structure
which has little to do with original functions. Once such structure
is available there is good chance that somebody will abuse it to
archive some good effect. But in most cases it would be better to
use another mechanizm. More specifically, serious complex numerical
computation can not depend on values on branch cuts -- simply
because of rounding error you never know whether you are exactly
on branch cut (you can only guarantee that you stay _away_ from
branch cut). So, only relatively trivial formulas (where you
can fully anayze roundoff) can use values on branch cuts. But
even then, it may well turn out (as is in our case) that the
values in not the needed one.
\start
Date: Wed, 17 Jan 2007 17:50:27 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: interpreter and with-expression
> On Wed, 17 Jan 2007 Tim Daly wrote:
>
> | > The interpreter (in particular pf2Sex) does not handle category
> | > definitions (with-expression). Is that by design or an "unfinished part"
> |
> | I'm not sure that it is possible to create categories at the
> | interpreter level. Well, in theory it is since a category is
> | simply a lisp expression, but in practice I don't think it works.
> | Categories are a compile-time concept.
>
> I'm unsure about the meaning you give to "compile-time" here.
>
> Types are compile-time concepts too. Yet, the interpreter has no
> problem handing
>
> Foo == Record(f: Integer, b: Boolean)
>
> or
>
> Bar := Record(f: Integer, b: Boolean)
>
>
> Furthermore within an axiom session, it is possible to )compile a file
> and have the result available in the working frame.
>
> I tripped over this while working on new packages for Axiom, and
> it really is confusing. I would like to know whether there are
> deep reasons for this, or whether it is because it was not
> finished.
>
In Axiom getting a "new" instance of an existing type is easy,
you just call the constructor. But to create a new type you
have to provide the constructor function. Effectively you have
to "compile" the type. In principle interpreter could transparently
pass the definition to the compiler, but IMHO differences in
interpreter and compiler language would destroy the illusion.
\start
Date: Wed, 17 Jan 2007 10:51:16 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Bug 215: sin asin(7.0::COMPLEX FLOAT)
On Wed, 17 Jan 2007, Waldek Hebisch wrote:
| Gabriel Dos Reis wrote:
| > Waldek Hebisch writes:
| > | However, the problem with asin is just one special case. We
| > | would like to support many multivalued special functions (which in
| > | numerical version require branch cuts). Tracking that we get
| > | "correct" values on cuts may well take significant portion of
| > | effert to implements those functions. OTOH computing with
| > | values on branch cuts does not seem very useful. So I am tempted
| > | to declare that arguments branch cuts are errors (like divison
| > | by 0).
| >
| > I'm concerned with that approach.
| >
| > After all, this is a mathematical computational platform. If we go
| > that way, how else can we expect other people to take branch cuts
| > seriously?
| >
|
| 1)
| What can be more serious than signaling error?
|
| 2)
| I am mathematician and I do not "take branch cuts seriously".
I'm a computational mathematician -- even though I ended up corrupted by
computer scientists -- and I do take branch cuts seriously.
[ In my PhD thesis work on Constant Mean Curvature surfaces, where
I did lot of numerical simulation and "construction", Riemann
surfaces were my benchwork. ]
| Serious math works with arbitrary branches, multivalued functions
| or Riemennian surfaces.
Which is why just signaling an error is not an option, from my perspective.
We must do better. See links below.
| Branch cuts are an artifical convention
| which pretends that multivalued functions can be used naively in
| numerical computations. In some sense it is an ideal field for
| standarisation: many choices are arbitrary, but for effective
| shortcut communication everybody should use the same choices.
| However, standarizing branch cuts produces a formal structure
| which has little to do with original functions. Once such structure
| is available there is good chance that somebody will abuse it to
| archive some good effect. But in most cases it would be better to
| use another mechanizm. More specifically, serious complex numerical
| computation can not depend on values on branch cuts
But, they do. And that is a matter of life Axiom has to take into
account if it ever has to be serious about "computational platform"
Somewhere we should record relevant literature on Axiom website.
http://www.cs.berkeley.edu/~fateman/papers/ding.ps
http://delivery.acm.org/10.1145/240000/235703/p21-patton.pdf?key1=235703&key2=4812509611&coll=GUIDE&dl=GUIDE&CFID=11704206&CFTOKEN=10201516
http://delivery.acm.org/10.1145/240000/235704/p25-rich.pdf?key1=235704&key2=9722509611&coll=GUIDE&dl=GUIDE&CFID=9284552&CFTOKEN=77401299
\start
Date: Wed, 17 Jan 2007 10:54:51 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: interpreter and with-expression
On Wed, 17 Jan 2007, Waldek Hebisch wrote:
| > On Wed, 17 Jan 2007 Tim Daly wrote:
| >
| > | > The interpreter (in particular pf2Sex) does not handle category
| > | > definitions (with-expression). Is that by design or an "unfinished part"
| > |
| > | I'm not sure that it is possible to create categories at the
| > | interpreter level. Well, in theory it is since a category is
| > | simply a lisp expression, but in practice I don't think it works.
| > | Categories are a compile-time concept.
| >
| > I'm unsure about the meaning you give to "compile-time" here.
| >
| > Types are compile-time concepts too. Yet, the interpreter has no
| > problem handing
| >
| > Foo == Record(f: Integer, b: Boolean)
| >
| > or
| >
| > Bar := Record(f: Integer, b: Boolean)
| >
| >
| > Furthermore within an axiom session, it is possible to )compile a file
| > and have the result available in the working frame.
| >
| > I tripped over this while working on new packages for Axiom, and
| > it really is confusing. I would like to know whether there are
| > deep reasons for this, or whether it is because it was not
| > finished.
| >
|
| In Axiom getting a "new" instance of an existing type is easy,
| you just call the constructor.
I'm sorry, that is bogus argument. Try )compile on a file that has
category and domain definitions.
| But to create a new type you
| have to provide the constructor function.
Of course. So?
| Effectively you have
| to "compile" the type. In principle interpreter could transparently
| pass the definition to the compiler, but IMHO differences in
| interpreter and compiler language would destroy the illusion.
Now, please do nail down those differences and and let see why they
are any useful in the specific issue at hand.
\start
Date: 17 Jan 2007 18:25:03 +0100
From: Francois Maltey
To: list
Subject: Re: Bug 215: sin asin(7.0::COMPLEX FLOAT)
Hi Waldek and all !
> Actually, now I am convinced that there is no simple "real" formula
> giving correct branch cuts. Official Lisp formula for asin is
> asin x == -%i*log(%i*x+sqrt(1-x^2))
> The Lisp formula stays away from branch cuts of logarithm, and only
> branch cut of sqrt matters (and defines brunch cuts of asin).
>
> So, to get correct asin we need a real function which contains
> -%i*log as the last step of computation. However, our only
> primitive of this sort is atan and contains spurious branch cut.
>
> So we probably need to provide a complex asin in Complex (or throw
> error for computations on branch cuts). We could also try to use
> complex formula in TrigonometricFunctionCategory
I don't see where the problem is in TrigonometricFunctionCategory
What is the problem if the axiom file trigcat.spad contains :
if R is a complex numeric ring then
asin can contains tests for ejecting problems in the atan special cases.
[or uses the log formula, if there is a log]
if R is a real numeric ring then
asin test the interval [-1, 1]
if R has log:R->R and imaginary:R->R then
asin x == -%i*log(%i*x+sqrt(1-x^2))
-- is the most serious method because it's the most known formula.
else ... I have no idea ...
It's almost necessary to have complex inside formal expression
because a sqrt(-1) can very quickly appear :
sqrt is an usual function and -1 is an usual number.
> I am affraid that Axiom assumes in too many places that real
> functions of real arguments are computed in "real way", we could
> easily get wrong results (starting from enexpected complex
> expressions to plain wrong).
Must this feature remains
or is it a good idea to retains axiom to claim that
Re(x+%i*y)=x and Im(x+%i*y)=y in usual cases.
Of corse theses equalities are right for algebraic computation,
but I (we?) also use axiom for analysis calculus...
I'll hope I can show/use axiom to/with my students
but in theses case I need calculus packages that are near
from maple/mupad/ti89 and so.
We might also think that axiom will use (some years later)
intervals for computation, it's useful for understand well posed formula :
test the 3 sequences.
u(n+1)=(8*u(n)-1)
with u(0) = 1/7
or u(0) = 1/7.0
or u(0) = the numerical interval [1/7-numerical error, 1/7+numerical error]
An other exercice I give sometimes to my students :
solve the formal z^4+2*m*z^2+1 polynomial in z,
and plot the curve solution into Complex plan for m in R.
Neither early maple nor early mupad do it with a finest way.
I don't know what axiom can do in this case.
Francois
Today my students noticed that I write log and not ln on the blackboard.
You understand why !
French stuents dislike, but what is the international function name.
\start
Date: Wed, 17 Jan 2007 19:50:18 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: interpreter and with-expression
Gabriel Dos Reis wrote:
> On Wed, 17 Jan 2007, Waldek Hebisch wrote:
> | In Axiom getting a "new" instance of an existing type is easy,
> | you just call the constructor.
>
> I'm sorry, that is bogus argument. Try )compile on a file that has
> category and domain definitions.
>
> | But to create a new type you
> | have to provide the constructor function.
>
> Of course. So?
>
> | Effectively you have
> | to "compile" the type. In principle interpreter could transparently
> | pass the definition to the compiler, but IMHO differences in
> | interpreter and compiler language would destroy the illusion.
>
> Now, please do nail down those differences and and let see why they
> are any useful in the specific issue at hand.
>
I am affraid that we miscomunicate: I was trying to reconstruct the
reasons why Axiom do not handle creating categories in the interpreter.
I do not defend the status quo.
Concerning differences, a little one which probably has no useful
justification: compiler accepts "until" keyword, but this keyword is
absent in the interpreter.
\start
Date: 17 Jan 2007 20:10:37 +0100
From: Martin Rubey
To: Gabriel Dos Reis
Subject: Re: interpreter and with-expression
Dear all,
Gabriel Dos Reis writes:
> The interpreter (in particular pf2Sex) does not handle category
> definitions (with-expression).
This sounds as if the interpreter would allow the definition of new
domains. However, from my experience, this is not the case.
I believe that both
> Foo == Record(f: Integer, b: Boolean)
>
> or
>
> Bar := Record(f: Integer, b: Boolean)
do not "really" define new domains. Foo is a macro that expands to
Record(f...), while Bar is a variable that is assigned Record(f...). However,
Record(f...) is an already defined domain, in fact, a very special one since it
is built in to the spad language (same holds for aldor, as far as I know).
For example, I get
(1) -> F: CoercibleTo OutputForm == add (Rep := Integer; coerce x == 1::OutputForm)
Internal Error
Unexpected error in call to system function pf2Sex1
Martin
> In case it is by design, what is the rationale?
Looking at the aldor interpreter (where both is possible), it seems that it is
quite difficult. It is the bit where I experienced most segfaults...
\start
Date: Wed, 17 Jan 2007 13:25:07 -0600 (CST)
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: interpreter and with-expression
On Wed, 17 Jan 2007, Martin Rubey wrote:
| For example, I get
|
| (1) -> F: CoercibleTo OutputForm == add (Rep := Integer; coerce x == 1::OutputForm)
| Internal Error
| Unexpected error in call to system function pf2Sex1
I know. That error is precisely why I asked the question.
What is the difference between putting that definition in a file
and subsequently issueing )co -- which will compile everything and
make it available in the working space -- as opposed to allowing
the definition at the interpreter level and process (almost) exactly
the same way?
\start
Date: Wed, 17 Jan 2007 13:38:58 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: interpreter and with-expression
On Wed, 17 Jan 2007, Waldek Hebisch wrote:
| Concerning differences, a little one which probably has no useful
| justification: compiler accepts "until" keyword, but this keyword is
| absent in the interpreter.
I believe the interpreter uses the "new parser" (src/interp/cparse.boot)
where "until" seems indeed missing. I don't know whether that is
by design or a bug. Note that that "new parser" is also intended
to be used by the "new compiler".
\start
Date: Wed, 17 Jan 2007 15:00:24 -0600
From: Tim Daly
To: Gabriel Dos Reis
Subject: interpreter and with-expression
> What is the difference between putting that definition in a file
> and subsequently issueing )co
The interpreter does not have the treewalking machinery to dynamically
construct and use a category. The compiler does.
\start
Date: Wed, 17 Jan 2007 15:19:09 -0600 (CST)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: interpreter and with-expression
On Wed, 17 Jan 2007 Tim Daly wrote:
| > What is the difference between putting that definition in a file
| > and subsequently issueing )co
|
| The interpreter does not have the treewalking machinery to dynamically
| construct and use a category. The compiler does.
(1) But, they are not really two separate software.
(2) the interpreter does what a category looks like syntactically.
So, instead of aborting with an obscure message, it can just
as well call the compiler sub-component with the parse tree
and has the compiler does the construction and loads the
resulting object.
\start
Date: 17 Jan 2007 22:20:35 +0100
From: Francois Maltey
To: Waldek Hebisch
Subject: Re: Zero divisors in Expression Integer
Dear Waldek,
Thanks a lot for your previous accurate reponse.
It seems you understand what I'm looking for,
and I hope understand how you want axiom computes.
> I want Axiom to produce mathematically correct results.
> [and use] algebraic interpretation otherwise we get wrong results.
> To handle conventions used in calculus we need higher
> level packages.
> But the case analysis may get messy (after all the problem is
> undecidable) and will have to give up (say return expression
> unevaluated).
For students I must have a minimal analysis point of view.
It's right, axiom can have both points of view with (many) domains.
1/ algebraic domains which are really right
and 2/ others domains for usual calculus, less perfect but more usual...
> This is impossible if you want to stay in a single domain.
> [I cut the two pretty examples with exp and log]
> So really each Axiom domain must implement its on simplifications.
I agree, I recognize I forget this notion when I began to study elemntry.spad.
> Have you thought how your work fits into Axiom design?
First I thought it was the aim of Expression.
But now I recognize it's perhaps a bad idea.
Hi Everybody !
Do you have any idea about calculus domain for easy computation
as Maple, mupad and other Texas pocket calculators ?
Do you have an .axiom.input for students and professors ?
By example my students don't know the minimal polynomial for algebraic number,
so the reponse true for this calculus is too curious :
[axiom] a := 3 + sqrt 5 ; test ((a^2)^(1/2)=-a) --- the reponse is true
So for theses computations I pefer to use RealClosure than AlgebraicNumber ;
and I expect to have a smaller axiom, but a consistent system.
Please, give me some advices !
\start
Date: 17 Jan 2007 22:38:41 +0100
From: Francois Maltey
To: Gabriel Dos Reis
Subject: re: interpreter and with-expression
Dear Gabriel,
If you are looking in the interpreter is it possible to improve axion
about anonymous functions :
[t+k for k in 1..12] -- is right in axiom
[(t+->t+k) for k in 1..12] -- I can't get 12 functions with 12 integers.
[t +-> t+1, t +-> t+2] -- is well declared, but I can't sign it
map (f +-> f(55), [t +-> t+1, t +-> t+2])-- doesn't work, I must sign it
Do you have any information about the anonymous functions.
\start
Date: Wed, 17 Jan 2007 16:01:15 -0600 (CST)
From: Gabriel Dos Reis
To: Francois Maltey
Subject: re: interpreter and with-expression
On Wed, 17 Jan 2007, Francois Maltey wrote:
| Dear Gabriel,
|
| If you are looking in the interpreter is it possible to improve axion
| about anonymous functions :
|
| [t+k for k in 1..12] -- is right in axiom
| [(t+->t+k) for k in 1..12] -- I can't get 12 functions with 12 integers.
|
| [t +-> t+1, t +-> t+2] -- is well declared, but I can't sign it
| map (f +-> f(55), [t +-> t+1, t +-> t+2])-- doesn't work, I must sign it
|
| Do you have any information about the anonymous functions.
I have not come to that point yet.
So far, I only have documentation for
* lexing
* parsing (new compiler)
* parts of the interpreter (parsing excluded)
* lisplib generation
But, I'll definitely look into the anonymous functions. Thanks for
providing the test case.
\start
Date: 18 Jan 2007 22:44:49 +0100
From: Francois Maltey
To: Waldek Hebisch
Subject: Re: Zero divisors in Expression Integer
Hello Waldek,
In this previous mail you write :
> This is impossible if you want to stay in a single domain.
> For example, I freqently use the formula:
>
> exp(x)-exp(y) = integrate(exp((1-s)*x)*(y-x)*exp(s*y), s=0..1)
>
> valid when x and y are (no commuting) operators. This formula
> would be ruined by usual simplifications of exponentials.
Do you use the domain Expression for this ?
It seems that domain Expression is commutative for * ?
If so for a student/naive/general/teaching use it's only necessary to
load the naivePackage for the same domain expression.
If we want algebraic rule as you describe an other package over the same
domain will be better.
> So really each Axiom domain must implement its on simplifications.
In this case I'm not sure.
> You are doing nice things with expressions. But have you thought
> how your work fits into Axiom design?
The Question remains.
\start
Date: Fri, 19 Jan 2007 13:31:27 +0100 (CET)
From: Franz Lehner
To: list
Subject: axiom/aldor oddities
Hello again,
thank you for all your help you gave last time.
I am still new to axiom/aldor and perhaps somebody can point out
to me the difference between the following two snippets:
---BEGIN strange.as
#include "axiom"
FPI ==> Fraction Polynomial Integer;
tfpi1(d:Polynomial Integer,n:PositiveInteger): Fraction Polynomial Integer
== {
import from Integer;
(1/factorial(n::Integer)^2)::FPI*d;
}
tfpi2(d:Polynomial Integer,n:PositiveInteger): Fraction Polynomial Integer
== {
import from Integer;
(1/factorial(n::Integer)::FPI)^2::PositiveInteger*d;
}
---END strange.as
both functions compile fine with aldor and apparently should give the same
result, however axiom (version 20060621 on Debian) does not think this
way:
---BEGIN axiom
(4) -> tfpi1(x,3)
Looking in Polynomial(Integer()) for ??200088 with code 250738832
>> System error:
FOAM-USER::|fiRaiseException| is invalid as a function.
(4) -> tfpi2(x,3)
(4) ->
x
(4) --
36
Type: Fraction Polynomial
Integer
---END axiom
what am I missing here?
\start
Date: 19 Jan 2007 13:57:40 +0100
From: Martin Rubey
To: Franz Lehner
Subject: Re: axiom/aldor oddities
Dear Franz,
I can only guess...
Franz Lehner writes:
> ---BEGIN strange.as
> #include "axiom"
>
> FPI ==> Fraction Polynomial Integer;
>
> tfpi1(d:Polynomial Integer,n:PositiveInteger): Fraction Polynomial Integer == {
> import from Integer;
> (1/factorial(n::Integer)^2)::FPI*d;
> }
3B
* 1 is interpreted as an Integer (because of import from Integer)
* factorial is interpreted as factorial: % -> % from Integer (again because of
the import from Integer)
* ^ ditto
* but there is no / in Integer. I have no idea which function the compiler
finds here. In any case:
> (4) -> tfpi1(x,3)
> Looking in Polynomial(Integer()) for ??200088 with code 250738832
>
> >> System error:
> FOAM-USER::|fiRaiseException| is invalid as a function.
this looks like axiom couldn't find some function. It would be nice to know
which one, of course...
I think the following should work:
tfpi1(d:Polynomial Integer,n:PositiveInteger): Fraction Polynomial Integer == {
import from Integer, Fraction Integer;
(1/factorial(n::Integer)^2)::FPI*d;
}
or
tfpi1(d:Polynomial Integer,n:PositiveInteger): Fraction Polynomial Integer == {
import from Integer;
d/(factorial(n::Integer)^2)::(Polynomial Integer);
}
\start
Date: Fri, 19 Jan 2007 08:24:37 -0500
From: Bill Page
To: list
Subject: FW: Axiom is an open source math project
-----Original Message-----
From: Francesco Montorsi
Bill Page ha scritto:
> Dear MathStudio Webmaster,
>
> You wrote: "if you find other good links, please email them to the
> webmaster."
>
> See:
>
> http://wiki.axiom-developer.org
>
> Axiom is a general purpose system for doing mathematics by computer. It
> is especially useful for symbolic calculations, mathematical research and
> for the development of new mathematical algorithms. Axiom has a strongly-
> typed high-level programming language for expressing abstract mathematical
> concepts. Over 1,000 mathematical domains and categories are collected in
> the Axiom Library. ...
>
> Please list Axiom on your web page at
>
> http://mathstudio.sourceforge.net/links.shtml
done, thanks!
\start
Date: Fri, 19 Jan 2007 17:04:04 +0100
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: axiom/aldor oddities
Hello,
I also played a bit with your code, but I cannot quite give the same
reasoning as Martin.
On 01/19/2007 01:57 PM, Martin Rubey wrote:
> Dear Franz,
>
> I can only guess...
>
> Franz Lehner writes:
>
>> ---BEGIN strange.as
>> #include "axiom"
>>
>> FPI ==> Fraction Polynomial Integer;
>>
>> tfpi1(d:Polynomial Integer,n:PositiveInteger): Fraction Polynomial Integer == {
>> import from Integer;
>> (1/factorial(n::Integer)^2)::FPI*d;
>> }
> 3B
> * 1 is interpreted as an Integer (because of import from Integer)
The compiler actually has 3 choices
Polynomial Integer
Positive Integer
Fraction Polynomial Integer
since they appear in the input and output types of tfpi1. For the input
types I am pretty sure that Aldor automatically imports them. I am not
so sure with the output type, but that could be tested easily.
Unfortunately, I cannot point to the right place in the Aldor User
Guide, but (maybe) one cannot even clearly find it -- I simply don't
know by heart.
And there is a fourth choice coming from "import from Integer".
It is a bit hard now to look for a function /.
> * factorial is interpreted as factorial: % -> % from Integer (again because of
> the import from Integer)
>
> * ^ ditto
>
> * but there is no / in Integer. I have no idea which function the compiler
> finds here.
Me too. Interestingly the compiler says
woodpecker:~/scratch>aldor -mno-mactext -mno-abbrev strange.as
"strange.as", line 9: (1/factorial(n::Integer)^2)::FPI*d;
...................................^
[L9 C36] #1 (Error) (After Macro Expansion) There are 2 meanings for the
operator `coerce'.
Meaning 1: Fraction(Integer) -> Fraction(Polynomial(Integer))
Meaning 2: Polynomial(Integer) -> Fraction(Polynomial(Integer))
Expanded expression was: Fraction(Polynomial(Integer))
If one additionally says "import from Fraction Integer;". That seems
like the coerce function is causing trouble.
Note that a::T should be equivalent to coerce(a)@T. But it does not tell
from which domain/package the coerce should come. I faintly remember
that I have resolved segfaults just by writing coerce(a) instead of a::T.
Unfortunately, the compiler is not saying where it finds meaning 1 and
2. So I cannot say what goes wrong. But what I dont understand is: why
is the second meaning an option for the compiler. How can it deduce the
type of 1/something to be Polynomial(Integer)???
What about
tfpi1(d:Polynomial Integer,n:PositiveInteger): Fraction Polynomial
Integer == {
import from Integer;
f: Z := factorial(n::Z);
q: Q := 1/f^2;
(q::FPI) * (d :: FPI);
}
It is never bad to add a bit of redundancy (namely the types). It's
easier for humans and it helps the compiler.
\start
Date: Fri, 19 Jan 2007 15:55:06 -0600
From: Jaroslov Rosenberger
To: list
Subject: Problems with compiler::link
The platform is Ubuntu Edgy Eft 6.10. I attempted to build a fresh checkout
of build-improvements. It fails with the following error:
>/usr/bin/ld: cannot find -lSM
collect2: ld returned 1 exit status
SM is available on the system (/usr/lib/libSM.so.6 &
/usr/lib/libSM.so.6.0.0)
cheers,
-Jacob S.
\start
Date: Fri, 19 Jan 2007 16:04:21 -0600
From: Jaroslov Rosenberger
To: list
Subject: Re: Problems with compiler::link
Appears to be solved by installing dev-versions of gmp, gcl, X11, readline,
etc. These install the correct links for development.
-Jacob S.
On 1/19/07, Jaroslov Rosenberger wrote:
>
> The platform is Ubuntu Edgy Eft 6.10. I attempted to build a fresh
> checkout of build-improvements. It fails with the following error:
>
> >/usr/bin/ld: cannot find -lSM
> collect2: ld returned 1 exit status
>
> SM is available on the system (/usr/lib/libSM.so.6 &
> /usr/lib/libSM.so.6.0.0)
\start
Date: Sat, 20 Jan 2007 13:05:41 +0100
From: Gregory Vanuxem
To: list
Subject: breakmode handling bug ?
Hello,
It is possible in Axiom to modify its behavior when an error is
encountered via
)set break something
But if you set it to 'query', Axiom will ask you if you want to return
to top level or enter a Lisp break loop. What I find strange is that
this not what Axiom has to do. The code is (g-error.boot):
=======================================================================
msgQ :=
$cclSystem =>
['%l,'" You have two options. Enter:",'%l,_
'" ",:bright '"top ",'" to return to top level, or",'%l,_
'" ",:bright '"break ",'" to enter a LISP break loop.",'%l,_
'%l,'" Please enter your choice now:"]
['%l,'" You have three options. Enter:",'%l,_
'" ",:bright '"continue",'" to continue processing,",'%l,_
'" ",:bright '"top ",'" to return to top level, or",'%l,_
'" ",:bright '"break ",'" to enter a LISP break loop.",'%l,_
'%l,'" Please enter your choice now:"]
x := STRING2ID_-N(queryUser msgQ,1)
x :=
$cclSystem =>
selectOptionLC(x,'(top break),NIL)
selectOptionLC(x,'(top break continue),NIL)
null x =>
sayBrightly bright '" That was not one of your choices!"
========================================================================
>From the code (since $cclSystem is set to false) we have three options
and not two. On my machine I have only two choices. I added code to
PRINT the value of $cclSystem and $msgQ, something is wrong here
$cclSystem is set to false and msqQ holds the cclSystem message. I do
not have time right now to investigate further so I submit it here,
maybe you can understand what is going on here.
Is it a bug in GCL ? or in Axiom ?
Am I missing something ?
Greg
PS : To test it issue a ')set break query' followed by a ')lisp ub' for
example.
\start
Date: Sat, 20 Jan 2007 13:43:26 +0100 (CET)
From: Waldek Hebisch
To: Gregory Vanuxem
Subject: Re: breakmode handling bug ?
> Hello,
>
> It is possible in Axiom to modify its behavior when an error is
> encountered via
>
> )set break something
>
> But if you set it to 'query', Axiom will ask you if you want to return
> to top level or enter a Lisp break loop. What I find strange is that
> this not what Axiom has to do. The code is (g-error.boot):
>
Could you give more detail on what Axiom is doing for you and what
it to do. For me it works as follows (both the old release and
newest wh-sandbox):
(1) -> )set break query
(1) -> 1/0
>> Error detected within library code:
division by zero
protected-symbol-warn called with (NIL)
You have three options. Enter:
continue to continue processing,
top to return to top level, or
break to enter a LISP break loop.
Please enter your choice now:
continue
Processing will continue where it was interrupted.
(1) ->
\start
Date: Sat, 20 Jan 2007 18:57:35 +0100
From: Gregory Vanuxem
To: Waldek Hebisch
Subject: Re: breakmode handling bug ?
Le samedi 20 janvier 2007 =E0 13:43 +0100, Waldek Hebisch a =E9crit :
> > Hello,
> >
> > It is possible in Axiom to modify its behavior when an error is
> > encountered via
> >
> > )set break something
> >
> > But if you set it to 'query', Axiom will ask you if you want to return
> > to top level or enter a Lisp break loop. What I find strange is that
> > this not what Axiom has to do. The code is (g-error.boot):
> >
>
> Could you give more detail on what Axiom is doing for you and what
> it to do. For me it works as follows (both the old release and
> newest wh-sandbox):
>
> (1) -> )set break query
> (1) -> 1/0
>
> >> Error detected within library code:
> division by zero
>
> protected-symbol-warn called with (NIL)
>
> You have three options. Enter:
> continue to continue processing,
> top to return to top level, or
> break to enter a LISP break loop.
>
> Please enter your choice now:
> continue
> Processing will continue where it was interrupted.
> (1) ->
You version seems to correctly handle the piece of code I sent. I have
only two choices:
(1) -> 1/0
>> Error detected within library code:
division by zero
You have two options. Enter:
top to return to top level, or
break to enter a LISP break loop.
Please enter your choice now:
top
(1) ->
It's is on the x86_64 arch. I can reproduce this with gold,
build-improvements and an old one (from Debian).
Anyone who has a x86_64 version of GCL/Axiom can test this ?
\start
Date: Sat, 20 Jan 2007 19:23:02 +0100 (CET)
From: Waldek Hebisch
To: Gregory Vanuxem
Subject: Re: breakmode handling bug ?
> You version seems to correctly handle the piece of code I sent. I have
> only two choices:
>
> (1) -> 1/0
>
> >> Error detected within library code:
> division by zero
>
>
> You have two options. Enter:
> top to return to top level, or
> break to enter a LISP break loop.
>
> Please enter your choice now:
> top
> (1) ->
>
> It's is on the x86_64 arch. I can reproduce this with gold,
> build-improvements and an old one (from Debian).
>
> Anyone who has a x86_64 version of GCL/Axiom can test this ?
>
I use x86_64. My Axiom is based on gcl-2.6.7. One machine is
a Debian and uses system gcl, another one uses gcl-2.6.7 build
separately from sources (I do not use bundled gcl to save build
time).
\start
Date: Sat, 20 Jan 2007 20:14:28 +0100
From: Gregory Vanuxem
To: Waldek Hebisch
Subject: Re: breakmode handling bug ?
Le samedi 20 janvier 2007 =E0 19:23 +0100, Waldek Hebisch a =E9crit :
> > It's is on the x86_64 arch. I can reproduce this with gold,
> > build-improvements and an old one (from Debian).
> >
> > Anyone who has a x86_64 version of GCL/Axiom can test this ?
> >
>
> I use x86_64. My Axiom is based on gcl-2.6.7. One machine is
> a Debian and uses system gcl, another one uses gcl-2.6.7 build
> separately from sources (I do not use bundled gcl to save build
> time).
>
Hmm... I don't like that...
Thanks,
Greg
==========================
==========================
===============
Linux ellipse 2.6.19.1 #1 PREEMPT Mon Jan 8 18:08:50 CET 2007 x86_64
GNU/Linux
$ dpkg -l libc6
ii libc6 2.3.6.ds1-8 GNU C Library:
Shared libraries
GCL-2.6.7 and 2.6.8pre
Debian (testing)
\start
Date: Sat, 20 Jan 2007 14:14:27 -0500
From: Bill Page
To: Gregory Vanuxem, Waldek Hebisch
Subject: RE: breakmode handling bug ?
On January 20, 2007 12:58 PM Vanuxem Gregory wrote:
> I have only two choices:
>
> ) -> 1/0
>
> >> Error detected within library code:
> division by zero
>
> You have two options. Enter:
> top to return to top level, or
> break to enter a LISP break loop.
>
> Please enter your choice now:
> top
> (1) ->
> It's is on the x86_64 arch. I can reproduce this with gold,
> build-improvements and an old one (from Debian).
>
> Anyone who has a x86_64 version of GCL/Axiom can test this ?
>
Both my Fedora Core 3 x86-64 (AMD 3700) version (built from
build-improvements with included gcl-2.6.8pre) and the much
older Windows version (based on gcl-2.6.5, I think) both work
as expected and show 3 options.
\start
Date: Sun, 21 Jan 2007 20:24:12 -0800
From: Arthur Ralfs
To: list
Subject: retrieving axiom commands
Is it possible to retrieve axiom commands?
i.e. if I type in integrate(x**2,x) can I then get
that command back rather than the output from
the command?
\start
Date: Mon, 22 Jan 2007 09:51:40 -0500
From: Bill Page
To: Arthur Ralfs
Subject: RE: retrieving axiom commands
On January 21, 2007 11:24 PM Arthur Ralfs asked:
>
> Is it possible to retrieve axiom commands?
> i.e. if I type in integrate(x**2,x) can I then get
> that command back rather than the output from
> the command?
>
Try the command:
)history )show
Is that what you want?
\start
Date: Mon, 22 Jan 2007 14:38:52 -0800
From: Arthur Ralfs
To: list
Subject: clarification Re: retrieving axiom commands
I want to retrieve the command from within spad code,
not from the command line
Thanks
Arthur Ralfs wrote:
> Is it possible to retrieve axiom commands?
> i.e. if I type in integrate(x**2,x) can I then get
> that command back rather than the output from
> the command?
\start
Date: Tue, 23 Jan 2007 11:33:47 -0500
From: Bill Page
To: Arthur Ralfs
Subject: RE: clarification Re: retrieving axiom commands
On January 22, 2007 5:39 PM Arthur Ralfs wrote:
>
> I want to retrieve the command from within spad code,
> not from the command line
>
> Thanks
>
> Arthur Ralfs wrote:
> > Is it possible to retrieve axiom commands?
> > i.e. if I type in integrate(x**2,x) can I then get
> > that command back rather than the output from
> > the command?
> >
Oh ok, that's different. I don't think there is an standard
interface to do this but you can resort to accessing the
underlying Boot/Lisp variable |$currentLine|. See documentation
about the Axiom interpreter "top level loop" here:
http://wiki.axiom-developer.org/axiom--test--1/src/interp/IntTopBoot
http://wiki.axiom-developer.org/axiom--test--1/src/interp/IntintLisp
For example:
(1) -> )lisp (print |$currentLine|)
")lisp (print |$currentLine|)"
Value = ")lisp (print |$currentLine|)"
(2) -> _$currentLine$Lisp
(2) _$currentLine$Lisp
Type: Sexpression
In SPAD you can write something like this:
--- File: CommandLine.spad ---
)abbrev package CL CommandLine
CommandLine(): Exports == Implementation where
Exports ==> with
current: () -> String
Implementation ==> add
current() ==
-- if $currentLine is a list, command is last entry
if list?(_$currentLine$Lisp)$SExpression then
string last(_$currentLine$Lisp)$Lisp
else
string _$currentLine$Lisp
--- end ---
(3) -> )co CommandLine.spad
Compiling AXIOM source code from file
...
(3) -> current()$CommandLine
Loading
/Documents and Settings/Administrator.ASUS/My Documents/CL.NRLIB/code
for package CommandLine
(3) "current()$CommandLine"
Type: String
\start
Date: Tue, 23 Jan 2007 19:55:45 -0800
From: Arthur Ralfs
To: list
Subject: Re: clarification Re: retrieving axiom commands
Bill Page wrote:
> On January 22, 2007 5:39 PM Arthur Ralfs wrote:
>
>> I want to retrieve the command from within spad code,
>> not from the command line
>>
>> Thanks
>>
>> Arthur Ralfs wrote:
>>
>>> Is it possible to retrieve axiom commands?
>>> i.e. if I type in integrate(x**2,x) can I then get
>>> that command back rather than the output from
>>> the command?
>>>
>>>
>
> Oh ok, that's different. I don't think there is an standard
> interface to do this but you can resort to accessing the
> underlying Boot/Lisp variable |$currentLine|. See documentation
> about the Axiom interpreter "top level loop" here:
>
> http://wiki.axiom-developer.org/axiom--test--1/src/interp/IntTopBoot
> http://wiki.axiom-developer.org/axiom--test--1/src/interp/IntintLisp
>
> For example:
>
> (1) -> )lisp (print |$currentLine|)
>
> ")lisp (print |$currentLine|)"
> Value = ")lisp (print |$currentLine|)"
>
> (2) -> _$currentLine$Lisp
>
> (2) _$currentLine$Lisp
> Type: Sexpression
>
> In SPAD you can write something like this:
>
> --- File: CommandLine.spad ---
> )abbrev package CL CommandLine
> CommandLine(): Exports == Implementation where
> Exports ==> with
> current: () -> String
> Implementation ==> add
> current() ==
> -- if $currentLine is a list, command is last entry
> if list?(_$currentLine$Lisp)$SExpression then
> string last(_$currentLine$Lisp)$Lisp
> else
> string _$currentLine$Lisp
>
> --- end ---
>
> (3) -> )co CommandLine.spad
> Compiling AXIOM source code from file
> ...
>
> (3) -> current()$CommandLine
> Loading
> /Documents and Settings/Administrator.ASUS/My Documents/CL.NRLIB/code
> for package CommandLine
>
> (3) "current()$CommandLine"
> Type: String
>
>
> Does that help?
>
> Regards,
> Bill Page.
>
>
Thank you, that's very helpful, although it turns out that
$internalHistoryTable has
the information I need, rather than $currentLine.
\start
Date: Wed, 24 Jan 2007 10:32:53 -0500
From: Bill Page
To: Arthur Ralfs
Subject: RE: clarification Re: retrieving axiom commands
On January 23, 2007 10:56 PM Arthur Ralfs
>
> Bill Page wrote:
> > ....
> > In SPAD you can write something like this:
> >
> > --- File: CommandLine.spad ---
> > )abbrev package CL CommandLine
> > CommandLine(): Exports == Implementation where
> > Exports ==> with
> > current: () -> String
> > Implementation ==> add
> > current() ==
> > -- if $currentLine is a list, command is last entry
> > if list?(_$currentLine$Lisp)$SExpression then
> > string last(_$currentLine$Lisp)$Lisp
> > else
> > string _$currentLine$Lisp
> >
> > --- end ---
> >
> > ...
> > Does that help?
> >
> Thank you, that's very helpful, although it turns out that
> $internalHistoryTable has the information I need, rather
> than $currentLine.
>
Great.
Concerning $internalHistoryTable, I worry that this variable
might not always have the information that you need. Consider
the effect of the command:
(1) -> )history )file myhistory
When the history facility is active, history information will be
maintained in a file (and not in an internal table).
which is (more and less) described here:
http://wiki.axiom-developer.org/axiom--test--1/src/interp/IHistBoot
See also
)history [ )on | )off ]
Of course, this depends on exactly what and when you want to do
what you want to do. :-)
\start
Date: Fri, 26 Jan 2007 10:45:24 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: How to expand a fraction (like Maple does with'expand')?
Cc: Thomas Wiesner
Martin,
I prefer to reply to your email on the axiom-developer list rather
that the axiom-user list because I think the issues that you raise
are not so much related to "how to use" Axiom but rather more about
"how Axiom works" and possibly design and re-design. I would like
to invite Thomas to subscribe to one or both of these Axiom email
lists if he has an interest in following further discussion.
On January 26, 2007 6:20 AM Martin Rubey wrote:
>
> although for the end-user it probably doesn't matter, I'm afraid
> that the impression the mails by Bill Page and Francois Maltey
> give is not quite "complete".
Yes I agree, which is the reason I think it is worth some time
to continue this thread on the developer list.
>
> * in Axiom, it is very important to distinguish between
> internal representation and output.
>
Yes! But of course this is a problem for novice Axiom users. In
comparison with Maple (and most other CA systems), Axiom's focus
on internal representation makes things immediately seem more
complicated then they "need to be". I think this is very bad for
new users.
Secondly, making Axiom's output non-trivially related to the
internal representation creates a barrier and a steep learning
curve since in many cases it turns out that "things are not what
they appear to be". Thus Axiom as it exists today violates the
"principle of least surprise" many times over. Some people treat
this as a challenge while others find it very repulsive to
continued use of Axiom.
> * "expand" as provided by Maple, Mathematica, etc., is mainly
> about output, the internal representation doesn't matter too
> much there. It can be interpreted as: display the thing with
> everything multiplied out.
>
I do not agree. Having used Maple extensively I would say that
when using the expand operator I do not have the sense of merely
affecting a desired output. I think it is wrong to say that
"internal representation doesn't matter". Rather it is more that
case that there is only one internal representation - expression -
and one views expand as actively manipulating that representation.
Often one seeks a series of such manipulations that preserve the
algebraic structure but which lead to the desired result, e.g.
prove a theorem or compute some specific unknown.
> * in Axiom, if you want to have a different output, it is
> best to write a wrapper domain.
As soon as you suggest creating new types (domains) for specific
purposes I think you take the discussion beyond what most novice
users are whiling to accept (at least initially). This requires
a kind of "2nd order" thinking about a problem compared to the
usual straight forward analysis that most people apply to problem
solving. So I think it is important to separate "Axiom Users" into
at least two classes: those interested immediate "engineering-
oriented" results, and those willing to invest time and effort
into more general solutions.
>
> * it is very easy to write such a domain in Axiom. In Aldor,
> it would be even easier, but unfortunately, currently the
> necessary functionality ("extend") is not provided by the
> Axiom-Aldor interface.
Now, surely you realize that when you say "very easy to write",
you are not satisfying the expectations of the original question
which was to presume that a "simple" expand operation in Maple
should have a direct counter-part in Axiom?
>
> Here goes the domain. Put it into a file, for example
> myexpr.spad, type
>
> )co myexpr.spad
>
> on the axiom command prompt
>
> and
>
> (((-r1*r2*uoff)+((r2+r1)*r3+r1*r2)*ue)/(r2*r3))::DEXPR INT
>
> should return
>
> r1 ue r1 uoff r1 ue
> ----- - ------- + ----- + ue
> r3 r3 r2
>
I think this result is wonderful but very unconvincing...
I recall that you have in fact presented this very solution
before in the context of a similar question. We previously
discussed the issue of whether it would make sense to
introduce a new domain constructor, say 'distributed' that
would operate in a manner analogous to Axiom's 'factored'
construction. Then one could write for example
Distributed Expression Integer
But the suggestion that the difference is merely one of
"appearance" of the resulting expression is still very
unsatisfying to me.
>
> ---myexpr.spad
> ----------------------------------------------------------------
> )abb domain DEXPR DistributedExpression
> DistributedExpression(R: Join(Ring, OrderedSet)): Exports ==
> Implementation where
> AN ==> AlgebraicNumber
> SUP ==> SparseUnivariatePolynomial
>
> EXPRR ==> Expression R
>
> Exports == FunctionSpace R with
> if R has IntegralDomain then
> AlgebraicallyClosedFunctionSpace R
> TranscendentalFunctionCategory
> CombinatorialOpsCategory
> LiouvillianFunctionCategory
> SpecialFunctionCategory
> reduce: % -> %
> ++ reduce(f) simplifies all the unreduced algebraic quantities
> ++ present in f by applying their defining relations.
> number?: % -> Boolean
> ++ number?(f) tests if f is rational
> simplifyPower: (%,Integer) -> %
> ++ simplifyPower?(f,n) \undocumented{}
> if R has GcdDomain then
> factorPolynomial : SUP % -> Factored SUP %
> ++ factorPolynomial(p) \undocumented{}
> squareFreePolynomial : SUP % -> Factored SUP %
> ++ squareFreePolynomial(p) \undocumented{}
> if R has RetractableTo Integer then RetractableTo AN
>
> Implementation == EXPRR add
>
> Rep := EXPRR
>
> out: (Polynomial R, %, List %, List %) -> OutputForm
> -- coerces the polynomial to OutputForm completely expanded
> and replaces the
> -- variables in vl with the kernels in kl
> out(p, q, kl, vl) ==
> ex: Fraction Rep := (eval(leadingMonomial(p)::%, vl,
> kl)::Rep)/(q::Rep)
> if reductum p = 0
> then coerce(ex)$Fraction(Rep)
> else coerce(ex)$Fraction(Rep) _
> + out(reductum p, q, kl, vl)
>
> coerce(ex:%):OutputForm ==
> kl := kernels ex
> vl: List % := [subscript('x,
> [i::OutputForm])::Symbol::% for i in 1..#kl]
> ex1: % := subst(ex, kl, vl)$%
> kl1 := map(coerce(#1)$%, kl)$ListFunctions2(Kernel %, %)
> if R has IntegralDomain then
> out(retract(numerator ex1)@Polynomial(R),
> denominator eval(ex1, vl, kl1), kl1, vl)
> else
> out(retract(ex1)@Polynomial(R), 1, kl1, vl)
> ---myexpr.spad
> ----------------------------------------------------------------
>
> A note for Thomas: the only bit of code that required some
> work was "out" and "coerce". Everything else (i.e., everything
> before and including "Rep:=EXPRR") is copy and paste. If the
> Aldor interface would work properly, it wouldn't be there.
Even with Aldor I would not count this as a solution that a novice
Axiom user could possibly apply.
>
> I'm sure that "out" and "coerce" could be simplified and
> improved, too. I just didn't bother.
>
> A note for axiom developers:
>
> In my opinion, this is not the right approach. The right
> approach would be to generalize DMP and to allow arbitrary
> variables, just as SMP does.
>
I would like to invite you to explain here in more detail what
you mean.
Personally I think it is a design mistake that Axiom has both a
MultivariatePolynomial domain and DistributedMultivariatePolynomial
domain. I think the model for the domain constructor 'Factored'
should have been followed where we have Polynomial(Integer) and
Factored(Polynomial Integer). Just as in the case of Factored,
the internal representation of Distributed would be different
than the underlying domain, e.g. the representation might be a
List structure those elements come from the underlying domain.
The operations in Distributed have to be "lifted" from the
underlying domain but applied to the new representation.
Then from a novice Axiom User's point of view, the proposed
domain constructor Distributed would (for the most part) just
take the place of Maple's expand operator. Of course in Axiom
there is much more to the story of types and domains then there
is in Maple, but one still has the "feeling" that one is
actively operating a some underlying internal representation
in a transparent and effective manner.
\start
Date: 26 Jan 2007 17:42:48 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: How to expand a fraction (like Maple does with'expand')?
Cc: Thomas Wiesner
Dear Bill, *,
Bill Page writes:
> > * "expand" as provided by Maple, Mathematica, etc., is mainly about output,
> > the internal representation doesn't matter too much there. It can be
> > interpreted as: display the thing with everything multiplied out.
> I do not agree.
That's exactly why I said that one should make DMP accept arbitrary
variables. Then the problem would go away, and furthermore, one would have an
efficient representation for the desired operations.
> As soon as you suggest creating new types (domains) for specific purposes I
> think you take the discussion beyond what most novice users are whiling to
> accept (at least initially).
I did not say that functionality like "expand" should not be provided. Quite
the opposite, in fact. However, since it is beyond my time to provide a good
solution, I presented a hack, that also shows how to create output you simply
cannot do in Maple et al. For example, I can imagine (but I do not know) that
it might be difficult in certain CAS to expand everything but keep the
denominator factored out. Or expand only with respect to certain variables,
etc.
> > * it is very easy to write such a domain in Axiom. In Aldor, it would be
> > even easier, but unfortunately, currently the necessary functionality
> > ("extend") is not provided by the Axiom-Aldor interface.
> Now, surely you realize that when you say "very easy to write", you are not
> satisfying the expectations of the original question which was to presume
> that a "simple" expand operation in Maple should have a direct counter-part
> in Axiom?
well, if "extend" were functional, I'd say, it would be really easy to
write. As of current state, I agree. And, again, I fully agree that "expand"
functionality should be present in Axiom.
> I think this result is wonderful but very unconvincing...
Well, you should take into account that it took me roughly 3 minutes (one of
them being compiling).
> I recall that you have in fact presented this very solution before in the
> context of a similar question.
Yes, but the desired output was different then. It kept the denominator
factored out...
> We previously discussed the issue of whether it would make sense to introduce
> a new domain constructor, say 'distributed' that would operate in a manner
> analogous to Axiom's 'factored' construction. Then one could write for
> example
> Distributed Expression Integer
I think that the idea of "Factored" is nice, I think I stated this before. I'm
not sure that it is to carry out. Furthermore, I'm not sure that the same idea
would make sense for Distributed.
> But the suggestion that the difference is merely one of "appearance" of the
> resulting expression is still very unsatisfying to me.
I did not intend to say that it should be that way. In fact, if you look at
symmetric functions, for example, the internal representation matters a lot. Of
course you can store them as polynomials. But then everything you do will be
horribly inefficient.
My "solution" is a hack, suitable for experimenting.
> > In my opinion, this is not the right approach. The right approach would be
> > to generalize DMP and to allow arbitrary variables, just as SMP does.
>
> I would like to invite you to explain here in more detail what
> you mean.
The signature of SMP is
SparseMultivariatePolynomial(R: Ring,VarSet: OrderedSet)
while the signature of DMP is
DistributedMultivariatePolynomial(vl,R): public == private where
vl : List Symbol
R : Ring
I'd propose to make it identical to the signature of SMP.
> Personally I think it is a design mistake that Axiom has both a
> MultivariatePolynomial domain and DistributedMultivariatePolynomial domain.
That may well be. Maybe you can try to design such a domain Distributed? I
think, the first steps would be to see which categories the argument has to
satisfy, and how you can "lift" the functionality of the argument domain.
For example, would Distributed EXPR INT provide exponentiation ^: (%, %) -> % ?
If so, what would the result of (a+b)^n be?
Would you provide eval?
eval((a+b)^n, n=3)
Consider:
(1) -> p: POLY INT
Type: Void
(2) -> p := a+x + a+y
(2) y + x + 2a
Type: Polynomial Integer
(4) -> factor p
(4) y + x + 2a
Type: Factored Polynomial Integer
(5) -> factor eval(p, x=y)
(5) 2(y + a)
Type: Factored Polynomial Integer
(6) -> eval(factor p, x=y)
(6) 2y + 2a
Type: Factored Polynomial Integer
(although, I must admit that this is simply a bug in Factored and could be
easily corrected. Currently it assumes that specializing does not affect
factorization)
\start
Date: Sat, 27 Jan 2007 01:59:10 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Re: How to expand a fraction
Cc: Thomas Wiesner
Wiesner Thomas wrote:
> How can i do the following (from Maple) in Axiom:
>
> expand(((-r1*r2*uoff)+((r2+r1)*r3+r1*r2)*ue)/(r2*r3));
>
> r1 uoff ue r1 ue r1
> - ------- + ue + ----- + -----
> r3 r2 r3
Modulo term order:
(14) -> x := ((-r1*r2*uoff)+((r2+r1)*r3+r1*r2)*ue)/(r2*r3)
- r1 r2 uoff + ((r2 + r1)r3 + r1 r2)ue
(14) --------------------------------------
r2 r3
Type: Fraction Polynomial Integer
(15) -> reduce(+, [box(k/denom(x)) for k in monomials(numer(x))])
r1 ue r1 ue r1 uoff
(15) ue + ----- + ----- + - -------
r2 r3 r3
Type: Expression Integer
How does it work: we split fraction into numerator and denominator, then
split numerator into separate terms (using 'monomials' function).
We divide each of the terms by the denominator and put an invisible box
around the resulting quotient. Then we add everything back together.
Some remarks:
1) box operator prevents simplification, so careful when you use it,
otherwise you may get unexpected results.
2) AFAIK expand command in Maple is really a cheaper version of
simplify (it is enoungh to simplify polynomials). More precisely,
Maple is doing very little (no??) simplification by default,
so you may have a complicated expression which is really 0.
Expand gives you "canonical" form for polynomials -- if two
polynomials are mathematically equal then the expanded forms
are equal. This is not needed in Axiom, Axiom normally keeps
polynomials (and rational functions) in "canonical" form.
If for some reasons other forms are preferable Axiom offers
some extra domains (like Factored).
3) AFAIU what you really want is a way to control how results are
printed. IIRC Axiom gives only very limited control over
formatting the output.
4) In general each systems has hardcoded ideas what looks best, and
it can be frustrating trying (with no effect) to match output of
the other system.
5) IMHO your Maple solution, the command I gave and Bill Page DMP
trick are really abuses: all of the commands perform some
computation and the change in printed output is a byproduct
(possibly unintended). I wrote above about Maple expand.
Axiom DMP was implemented to allow efficient computation of
Groebner bases (and some similar computation). I know very
little about box operator, but I suspect that it main intended
use was _not_ to control printing.
\start
Date: Fri, 26 Jan 2007 23:50:21 -0500
From: Bill Page
To: Waldek Hebisch
Subject: re: How to expand a fraction
Cc: Thomas Wiesner
On January 26, 2007 7:59 PM Waldek Hebisch wrote:
>
> Wiesner Thomas wrote:
>
> > How can i do the following (from Maple) in Axiom:
> >
> > expand(((-r1*r2*uoff)+((r2+r1)*r3+r1*r2)*ue)/(r2*r3));
> >
> > r1 uoff ue r1 ue r1
> > - ------- + ue + ----- + -----
> > r3 r2 r3
>
> Modulo term order:
>
> (14) -> x := ((-r1*r2*uoff)+((r2+r1)*r3+r1*r2)*ue)/(r2*r3)
>
> - r1 r2 uoff + ((r2 + r1)r3 + r1 r2)ue
> (14) --------------------------------------
> r2 r3
> Type: Fraction Polynomial Integer
>
> (15) -> reduce(+, [box(k/denom(x)) for k in monomials(numer(x))])
>
> r1 ue r1 ue r1 uoff
> (15) ue + ----- + ----- + - -------
> r2 r3 r3
> Type: Expression Integer
>
> How does it work: we split fraction into numerator and
> denominator, then split numerator into separate terms (using
> 'monomials' function). We divide each of the terms by the
> denominator and put an invisible box around the resulting
> quotient. Then we add everything back together.
>
Excellent! I think it is a clever solution. It is more
transparent than Martin's DistributedExpression solution and
it uses some operations that a novice Axiom user might already
understand and find useful for other purposes.
But an explanation is still required about the use of the
Expression domain versus polynomials and the choices that the
Axiom interpreter makes in this case.
> Some remarks:
>
> 1) box operator prevents simplification,
Perhaps you meant to say "evaluation" rather than "simplification".
It is misleading to take about simplification in this context.
It seems to me that Axiom never attempts any simplification as
such. It simply applies each operator that it selects based on
contextual and explicit type information as it parses some input.
The result of the calculation is a member of some domain which
may have an associated "canonical" OutputForm that appears similar
to an simplification of the input expression but really has nothing
directly to do with expression manipulation.
I think it is better to say that 'box' (and the related operator
'paren' in ES) simply remain unevaluated and have a particular
associated OutputForm. But the arguments of box, and expressions
involving box, are in fact evaluated by Axiom as the example below
shows.
> so careful when you use it, otherwise you may get unexpected
> results.
>
Indeed! For example
(16) -> box(1+2)+box(3)
(16) 23
Type: Expression Integer
[Note: This must be read a 2 * 3.]
(17) -> %::InputForm
(17) (* 2 (%box 3))
Type: InputForm
How to "unbox" an expression?
> 2) AFAIK expand command in Maple is really a cheaper version of
> simplify (it is enough to simplify polynomials). More
> precisely, Maple is doing very little (no??) simplification
> by default, so you may have a complicated expression which is
> really 0. Expand gives you "canonical" form for polynomials --
> if two polynomials are mathematically equal then the expanded
> forms are equal. This is not needed in Axiom, Axiom normally
> keeps polynomials (and rational functions) in "canonical" form.
Rather than speaking about "canonical forms", it is more accurate
to say that Axiom choices a particular internal representation for
each domain.
> If for some reasons other forms are preferable Axiom offers
> some extra domains (like Factored).
>
I would also add "like DistributedMultivariatePolynomial". See
further comment below.
> 3) AFAIU what you really want is a way to control how results
> are printed.
I disagree that the original intent of the question was necessarily
limited to "control how results are printed". The author asked:
"how do I expand an expression" as in the context of Maple. The
reason why one might want to manipulate an expression this way was
not stated but it certainly might include showing that two expressions
are equal such as you implied above.
> IIRC Axiom gives only very limited control over formatting the
> output.
>
As Martin's example showed, that is not true. Axiom's OutputForm
domain provides a very rich formatting environment (at the cost
of some programming in SPAD).
> 4) In general each systems has hardcoded ideas what looks best,
> and it can be frustrating trying (with no effect) to match
> output of the other system.
>
In Axiom I think it is important to realize that an "object" (i.e.
an member of a domain) has both an internal representation (hidden
except for the explicit operations exported by the interface) and
an external appearance as "hardcoded" by a particular coercion to
the OutputForm domain. How much of this one can or should say to a
novice Axiom user, I am uncertain. But everything else I have seen
written so far seems misleading to me.
> 5) IMHO your Maple solution, the command I gave and Bill Page
> DMP trick are really abuses: all of the commands perform some
> computation and the change in printed output is a by-product
> (possibly unintended). I wrote above about Maple expand.
> Axiom DMP was implemented to allow efficient computation of
> Groebner bases (and some similar computation).
I object to the phrase "trick" and "abuse". It seems to me that
what you, I and Martin wrote as "solutions" make good sense in
the appropriate context. I am not sure why you would claim that
the intended use of DMP is limited to efficient computation of a
given kind, however I agree of course that the choice of internal
representation of a domain does have a big impact on efficiency of
a given algorithm.
> I know very little about box operator, but I suspect that it
> main intended use was _not_ to control printing.
>
Clearly it is an operation in Axiom that is intended to facilitate
the manipulation of members of the Expression domain in (more or
less) the manner which you demonstrated. That his affects how
expressions are printed seems to me to be a natural consequence.
\start
Date: Fri, 26 Jan 2007 23:39:02 -0600
From: Tim Daly
To: list
Subject: browser front end, statement of plans and progress
I've been looking deeply into the problem of using a web browser
as the front end for axiom. There are 3 components:
1) replace the graphics
2) replace hyperdoc
3) make an interactive front end
Consider problem 1, replace the graphics.
Currently our graphics are written in C and use X11.
The graphics program is really a standalone C program that
communicates to the rest of the system thru sman.
X11 has been a problem because we cannot port this to windows easily.
I did manage to get hyperdoc working on windows using an X11 hosting
program but decided that this was not a good long term solution and
never released it.
Architecturally the choice of making the graphics engine exist outside
of the underlying lisp system has limitations. I would much rather see
a closer integration between the computations and their display so that
the display could be dynamic instead of static graphs. And it should be
possible to create new domains that directly manipulate axiom data
structures that can be drawn directly. A standalone C program is not
a good choice for this.
I've been investigating new browser technology that will allow us to
draw the graphics on a web page in several formats. The first attempt
was to create flash files (an open format) directly from lisp so that
we could write a flash file which had moving graphics (e.g. a moving
wave image). This proved to be painful and I stopped.
Recently a new html tag <canvas> has been implemented. I've been playing
with this tag and it appears to support all of the drawing primitives we
need to do the 2D graphics. Axiom already does the 3D->2D work.
Another recent (well, recent to me) development has been the AJAX
architecture. This allows a web page to dynamically and periodically
communicate to a host without changing the page. This is how google
does tricks like google earth.
So combining these two technologies will allow us to run an axiom
process that communicates with a local or remote browser and can
dynamically draw shapes on the webpage.
The low level task is to refactor the C code into display and
data handling. The display primitives get pushed out to javascript.
The data handling gets sucked into lisp. The C code disappears.
I'm putting together code to do an example for this and I'd like
feedback about the idea and the direction.
Consider problem 2, replace hyperdoc.
I've already coded portions of hyperdoc in javascript and am now
learning AJAX so that I can fetch pages and images from an axiom
session. Also in plan is to be able to dynamically show results
from the axiom session when looking up search and query information.
Hyperdoc used to have its own language for display but this is dead
and gone. I've been recoding the hyperdoc pages into html so they
use a standard format. This will allow anyone to code web pages without
any training. It should also allow us to embed pamphlets as pdf in pages.
The low level task is to recode the hyperdoc info into html and
javascript (in process), factor in new function for handling
pamphlets and hyperlinking to non-axiom data, and using either
mathml or some other smooth symbol output.
Hyperdoc can display both static (easy) and dynamic (somewhat harder)
graphics output so I'm stalled on the conversion while I work thru
the graphics details.
Consider problem 3, make an interactive front end
Given AJAX it should be possible to type into a web page, send the
input to axiom, html (mathml?) the output, and display the result.
This will take a bit of surgery on the axiom display internals and
is queued behind the first two problems.
The low level task involves rewriting the front end to do I/O
thru the web interface instead of a pty, killing off sman, and
making the I/O controllable by spad code.
The goal is to have a working browser-based front end to axiom
that works on any platform or across the net by next year.
By design all of the C code disappears and all work is done
inside the lisp image. The actual functions will be implemented
at the axiom/spad language level so that users can have complete
control of I/O directly in spad.
So the overall redesign calls for a lisp-only, browser fronted
axiom which uses html (maybe mathml, undecided), javascript and
a general browser (or any network program). All of the C code dies.
All of the hyperdoc language/machinery dies. Sman dies. All axiom
code is just a single lisp image.
Problem 4 is to move on to making the front end and back end
reflect the crystal/facet design. More about that when the first
3 parts begin to work.
Design suggestions and discussion are welcome.
\start
Date: Sat, 27 Jan 2007 08:14:04 +0100
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: browser front end, statement of plans and progress
Hello Tim,
On 01/27/2007 06:39 AM, Tim Daly wrote:
> I've been looking deeply into the problem of using a web browser
> as the front end for axiom. There are 3 components:
>
> 1) replace the graphics
> 2) replace hyperdoc
> 3) make an interactive front end
[snip]
> Consider problem 2, replace hyperdoc.
>
> I've already coded portions of hyperdoc in javascript and am now
> learning AJAX so that I can fetch pages and images from an axiom
> session. Also in plan is to be able to dynamically show results
> from the axiom session when looking up search and query information.
>
> Hyperdoc used to have its own language for display but this is dead
> and gone. I've been recoding the hyperdoc pages into html so they
> use a standard format. This will allow anyone to code web pages without
> any training. It should also allow us to embed pamphlets as pdf in pages.
>
> The low level task is to recode the hyperdoc info into html and
> javascript (in process), factor in new function for handling
> pamphlets and hyperlinking to non-axiom data, and using either
> mathml or some other smooth symbol output.
>
> Hyperdoc can display both static (easy) and dynamic (somewhat harder)
> graphics output so I'm stalled on the conversion while I work thru
> the graphics details.
HyperDoc also shows the API of SPAD programs, in particular the ++
comments. I know that you tend to remove the ++ stuff in favour of
literate programs, but their may be people (like me) who want to have
both. I would rather like to see a concise API description from where I
can quickly see that the function does what I would like it to do. Of
course that doesn't prevent us from putting a link to the actual
literate program part of the function into the API description. (Note
that I don't want to get rid of the literate programming idea, I just
want a different view on the documentation that pretty much looks like
an API description.)
Since you want to bring the documentation to html, what do you expect as
the input? If hyperdoc goes away, I probably guess rightly, that you
also want to remove hypertex, right?
\start
Date: Sat, 27 Jan 2007 08:14:50 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: browser front end, statement of plans and progress
> I've been looking deeply into the problem of using a web browser
> as the front end for axiom. There are 3 components:
>
> 1) replace the graphics
> 2) replace hyperdoc
> 3) make an interactive front end
>
> Consider problem 1, replace the graphics.
>
> Currently our graphics are written in C and use X11.
> The graphics program is really a standalone C program that
> communicates to the rest of the system thru sman.
>
> X11 has been a problem because we cannot port this to windows easily.
> I did manage to get hyperdoc working on windows using an X11 hosting
> program but decided that this was not a good long term solution and
> never released it.
>
X11 problem should be easy to solve: use portable drawing library.
It looks that SDL should work for us. In fact, we want to remove
direct X11 dependency in order to allow generating images in server
setting (when Axiom has no access to X server).
> Architecturally the choice of making the graphics engine exist outside
> of the underlying lisp system has limitations. I would much rather see
> a closer integration between the computations and their display so that
> the display could be dynamic instead of static graphs. And it should be
> possible to create new domains that directly manipulate axiom data
> structures that can be drawn directly. A standalone C program is not
> a good choice for this.
>
AFAICS standalone program was used because multithreading is available
only in some Lisps. The point is that you do not want to handle
interaction in the same thread that may be doing heavy computation.
Of course, putting interaction in web browser separates it from Lisp,
but then you have back limitations due to separate graphic engine.
> I've been investigating new browser technology that will allow us to
> draw the graphics on a web page in several formats. The first attempt
> was to create flash files (an open format) directly from lisp so that
> we could write a flash file which had moving graphics (e.g. a moving
> wave image). This proved to be painful and I stopped.
>
> Recently a new html tag <canvas> has been implemented. I've been playing
> with this tag and it appears to support all of the drawing primitives we
> need to do the 2D graphics. Axiom already does the 3D->2D work.
>
You mean: the Axiom C code in graphic subdirectory does the 3D->2D work.
> The low level task is to refactor the C code into display and
> data handling. The display primitives get pushed out to javascript.
> The data handling gets sucked into lisp. The C code disappears.
>
The graphic code is actually to some degree separated. There is (small)
part that supports graphic primitives, data handling part which converts
vector type specificaton send by AXIOMsys into primitives and interactive
part (responsible for user interaction). Bad thing is that interactive
part passes modifies in rather unstructured way parameters used for
data conversion. Also, data convertion needs color information and
takes it from X server (even for Postscript output).
> I'm putting together code to do an example for this and I'd like
> feedback about the idea and the direction.
>
>
>
> Consider problem 2, replace hyperdoc.
>
> I've already coded portions of hyperdoc in javascript and am now
> learning AJAX so that I can fetch pages and images from an axiom
> session. Also in plan is to be able to dynamically show results
> from the axiom session when looking up search and query information.
>
> Hyperdoc used to have its own language for display but this is dead
> and gone. I've been recoding the hyperdoc pages into html so they
> use a standard format. This will allow anyone to code web pages without
> any training. It should also allow us to embed pamphlets as pdf in pages.
>
Hyperdoc uses essentialy _the same_ TeX notation as Axiom book (and
contains the same material). IMHO this property should be preserved:
online and printed Axiom meterial should use the same sources.
If current format in inconvenient it is Axiom book which should be
recoded. For Web access we need a translator which converts our
format to HTML.
\start
Date: Sat, 27 Jan 2007 13:32:02 +0600 (NOVT)
From: Andrey G. Grozin
To: Tim Daly
Subject: Re: browser front end, statement of plans and progress
On Fri, 26 Jan 2007, Tim Daly wrote:
> I've been looking deeply into the problem of using a web browser
> as the front end for axiom. There are 3 components:
>
> 1) replace the graphics
> 2) replace hyperdoc
> 3) make an interactive front end
I still think that there is a better alternative than using a browser as a
front-end - GNU TeXmacs. Browsers are big and inefficient (especially
things like javascript); the quality of formulas is not really good.
There are exactly 2 programs which cac display high-quality maths - TeX
and TeXmacs, but TeX is non-interactive (attempts to run latex on each
output line are terribly inefficient). TeXmacs can easily replace hyperdoc
- it already has practically all the needed functionality, though sending
commands to Axiom for execution will require some programming (not very
much).
About graphics: the current graphics has a good feature that I can
interact with a plot (to a limited extent) by mouse and menus, without
re-running Axiom commands. I think this is very valuable, and should be
much extended. Ideally, I should be able to rotate, zoom, change scale
along each axis, change axis labelling, place light sources, chenge
textures of surfaces, etc. etc., and produce a live plot of a ray-tracer
quality. All of this is not possible in a browser. This requires opengl.
So, moving to a browser interface seems to me a big step backwards.
> Architecturally the choice of making the graphics engine exist outside
> of the underlying lisp system has limitations. I would much rather see
> a closer integration between the computations and their display so that
> the display could be dynamic instead of static graphs. And it should be
> possible to create new domains that directly manipulate axiom data
> structures that can be drawn directly. A standalone C program is not
> a good choice for this.
Yes, a more close coupling between graphics and computations is very
valuable. But why a browser? Its connection to Axiom computation engine is
very week.
> Recently a new html tag <canvas> has been implemented. I've been playing
> with this tag and it appears to support all of the drawing primitives we
> need to do the 2D graphics. Axiom already does the 3D->2D work.
This is by far insufficient for highly interactive high-quality graphics.
> Another recent (well, recent to me) development has been the AJAX
> architecture. This allows a web page to dynamically and periodically
> communicate to a host without changing the page. This is how google
> does tricks like google earth.
Isn't it a way to spend a lot of resources (CPU, memory, bandwidth) for
nothing?
> So combining these two technologies will allow us to run an axiom
> process that communicates with a local or remote browser and can
> dynamically draw shapes on the webpage.
Yes, if you are prepared to wait as long as for getting some responce from
google earth (with network bandwidths outside USA, it is terrible).
> The low level task is to refactor the C code into display and
> data handling. The display primitives get pushed out to javascript.
> The data handling gets sucked into lisp. The C code disappears.
Javascript is 100 - 1000 times less efficient than C. Also, no opengl, no
interactivity, etc.
> Consider problem 2, replace hyperdoc.
As I said, TeXmacs can do everything hyperdoc does. Now. A few lines of
scheme code are needed to send commands back to Axiom.
> Hyperdoc used to have its own language for display but this is dead
> and gone. I've been recoding the hyperdoc pages into html so they
> use a standard format. This will allow anyone to code web pages without
> any training. It should also allow us to embed pamphlets as pdf in pages.
Pamphlets are LaTeX (or at least they should be, if your excellent idea of
\begin{chunk} ... \end{chunk} will become reality). TeXmacs can display
LaTeX (and hence pamphlets) directly, without pdf. It can also edit them
in a wysiwyg fashiom, which you cannot do with pdf.
Also, re-coding hyperdoc pages to LaTeX should be easier than to html, and
LaTeX is (from my point of view) a better language. It is already used in
pamphlet files. Why introduce html for the help system? Why not to use
LaTeX here too?
> Hyperdoc can display both static (easy) and dynamic (somewhat harder)
> graphics output so I'm stalled on the conversion while I work thru
> the graphics details.
TeXmacs can display static and dynamic graphics with equal ease, if it's
.eps (or can be converted to .eps).
> Consider problem 3, make an interactive front end
>
> Given AJAX it should be possible to type into a web page, send the
> input to axiom, html (mathml?) the output, and display the result.
> This will take a bit of surgery on the axiom display internals and
> is queued behind the first two problems.
So much inefficient machinery for so simple task!
TeXmacs can send commands to Axiom right now. Currently, the communication
in the opposite direction is done by Axiom generating LaTeX and TeXmacs
displaying it. This should be changed. Serialization of formulas produced
by Axiom via LaTeX, mathml or whatever is inefficient and loses important
information. Parsing this text stream in a front-end is a senseless work,
and should be eliminated. It is easy to output Axiom expressions as
s-expressions, and to send them to TeXmacs, without losing any information
about their internal structure and semantics. TeXmacs can understand and
display formulas sent as s-expressions. Some small adjustments are needed,
of course: TeXmacs expects s-expressions formed according to some (rather
natural) rules. But it is, of course, *much* easier to write generation of
such s-expressions than generation of LaTeX or mathml.
> The goal is to have a working browser-based front end to axiom
> that works on any platform or across the net by next year.
>
> By design all of the C code disappears and all work is done
> inside the lisp image. The actual functions will be implemented
> at the axiom/spad language level so that users can have complete
> control of I/O directly in spad.
>
> So the overall redesign calls for a lisp-only, browser fronted
> axiom which uses html (maybe mathml, undecided), javascript and
> a general browser (or any network program). All of the C code dies.
> All of the hyperdoc language/machinery dies. Sman dies. All axiom
> code is just a single lisp image.
Deth of C code, Lisp image only - this is good. But I am against browsers,
mathml, javascript (which is as bad as C and *very* inefficient).
GNU TeXmacs is free and available on all platforms (recently, a Mac port
with a native MacOS interface appeared, but I cannot comment on it because
I don't have a Mac). It has an additional advantage: it is used as an
interface to Axiom, maxima, yacas, Mathematica, Maple, REDUCE, MuPAD,
Pari/GP, macaulay2, octave, scilab, matlab, R, ... (the list is too long
to continue). A user can cut-and-paste between systems (for example, I can
derive some large matrix in Axiom, and then to copy the Axiom output to
Octave input for further efficient numerical diagonalization). Some
improvements in TeXmacs will benefit many systems, not just Axiom. For
example, I am sure that intelligent line-breaking for long output formulas
should be written in scheme inside TeXmacs, then it will be used by Axiom,
maxima, etc. etc.
To conclude: I think TeXmacs should become an official front-end for
Axiom. If a browser front-end is an inevitable evil in our age, TeXmacs
should become an official front-end number 2.
\start
Date: 27 Jan 2007 02:36:18 -0600
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: browser front end, statement of plans and progress
Waldek Hebisch writes:
| > I've been looking deeply into the problem of using a web browser
| > as the front end for axiom. There are 3 components:
| >
| > 1) replace the graphics
| > 2) replace hyperdoc
| > 3) make an interactive front end
| >
| > Consider problem 1, replace the graphics.
| >
| > Currently our graphics are written in C and use X11.
| > The graphics program is really a standalone C program that
| > communicates to the rest of the system thru sman.
| >
| > X11 has been a problem because we cannot port this to windows easily.
| > I did manage to get hyperdoc working on windows using an X11 hosting
| > program but decided that this was not a good long term solution and
| > never released it.
| >
|
| X11 problem should be easy to solve: use portable drawing library.
Qt is available under windows
http://www.trolltech.com/developer/downloads/qt/windows
and so is FLTK
http://www.fltk.org/
I'm not quit convinced yet that the idea of removing the all the C
codes from Axiom is a good idea.
\start
Date: 27 Jan 2007 10:13:13 +0100
From: Martin Rubey
To: Tim Daly
Subject: Re: browser front end, statement of plans and progress
Dear Tim,
Although I'm happy that you are working on the documentation issues, I must say
that I'm extremely concerned about your approach to
> 2) replace hyperdoc
and, maybe most importantly, about our (i.e., mine and your) communication with
respect to these things. I very much hope that I misunderstood you.
As you know, Ralf has written an excellent environment for literate programs,
called ALLPROSE. (Environment is not entirely correct, in principle it consists
of some programs that convert your literate program into documentation and
code, plus some LaTeX environments that are not so different from HyperTeX's
ideas, but in contrast to them very well documented. I'd say that they are as
easy to use.)
Meanwhile, I use his conventions also to document my spad code, although I
cannot use all features of ALLPROSE there. (I hope everybody knows by know that
we managed to use ALLPROSE directly for Axiom programs written in Aldor, in
this setting, all of ALLPROSE works very nicely)
Some time ago I asked you whether asq could be used to fetch the documentation
information also dynamically, i.e., after a file has been compiled within the
axiom environment. This would be important to mimick a strong feature of
HyperDoc: After compiling a bunch of spad files with ")co file", all the
documentation is found by HyperDoc!
I faintly remember that you answered, that this would be easy, but I never
heard any further response.
> Hyperdoc used to have its own language for display but this is dead and
> gone. I've been recoding the hyperdoc pages into html so they use a standard
> format. This will allow anyone to code web pages without any training. It
> should also allow us to embed pamphlets as pdf in pages.
I am very much concerned about this paragraph. In fact, if html is going to be
used for documentation rather than LaTeX, I'll immediately quit the project. I
cannot find any sane reason to give up these concepts from ALLPROSE and
HyperDoc. Finally, I don't see any reason to embed pdf in pages when we can
generate html automatically. Browsers are made to display html, not pdf, I'd
guess.
> The low level task is to recode the hyperdoc info into html and javascript
> (in process),
Could you please be more specific here? What do you mean by hyperdoc info? The
api currently written within the ++ environments? The example pages? If this is
the case, you have nearly lost me. Why don't you use tex4ht to translate
HyperTeX to html?
Dynamic api-documentation given the literate program is an absolute must for
me. To this end, given the name of a function or constructor, a hyperdoc
replacement would need to be able to
* fetch the +++ environment corresponding to this constructor from the literate
program or a database compiled from the literate program, as it is done now
(libdb.text)
* render the documentation written therein, hyperlinked of course.
Here is an example what is currently put into libdb.text:
cFormalPowerSeriesCategory`1`x`(Ring)->Category`(R)`FORMALP`\begin{adusage}
Foo: \adthistype{} Integer with {...} == add {...} \end{adusage} \begin{addescription}{The category of formal power series.} \adthistype{} is the category of \useterm{formal power series} of the form \begin{gather} f = \sum_{n=0}^\infty {f_n x^n}. \end{gather} \end{addescription}
This was generated from:
\begin{+++}
\begin{adusage}
Foo: \adthistype{} Integer with {...} == add {...}
\end{adusage}
\begin{addescription}{The category of formal power series.}
\adthistype{} is the category of \useterm{formal power series} of
the form
\begin{gather}
f = \sum_{n=0}^\infty {f_n x^n}.
\end{gather}
\end{addescription}
\end{+++}
Of course, HyperDoc complains when trying to display that:
Unknown begin type \begin{adusage}
While parsing T71
Trying to print the next ten tokens
\} Foo \: \ 1027 \{ \} Integer with \{ \.
An important remark is that, apart from being put into libdb.text, the above
documentation snippet also appears in the "full" documentation, properly
hyperlinked and colored, of course.
--excursion--------------------------------------------------------------------
If you want to see that file, say
svn co svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/trunk
cd combinat/trunk/combinat
notangle -t8 Makefile.nw > Makefile
make dvi
or
make colored dvi
or, if you have tex4ht installed,
make colored html
--excursion--------------------------------------------------------------------
Tim, maybe you could try to build upon these things? Maybe you could use the
above documentation snippet to elaborate on your ideas: How would you like to
have this written? (I hope, not html?) I guess that it would be possible to
convert it to some other format (automatically, of course), before it is put
into the (currently libdb.text) database. In fact, I think that this is the
place where we would need somebody with your knowledge and abilities. Maybe you
can look at ALLPROSE and find out how to turn it into a hyperdoc replacement.
> factor in new function for handling pamphlets and hyperlinking to non-axiom
> data, and using either mathml or some other smooth symbol output.
Note that ALLPROSE can output a huge variety of formats: dvi, pdf, ps, html,
mathml, html+jsmath, ... (Of course this is a half lie, since really ALLPROSE
knows only LaTeX. But Ralf's command of tex4ht is quite good...)
After having said "make html", "cd doc" and "myfavoritebrowser combinat.html",
click on "FormalPowerSeriesCategory" (it's Section number is 11.2) for an
excellent example!
> By design all of the C code disappears and all work is done inside the lisp
> image.
I dislike C and like Lisp, too. But I have the feeling that throwing away
C code should not be a goal per se.
I very much hope that I could make my concerns understood.
\start
Date: 27 Jan 2007 10:30:20 -0600
From: Gabriel Dos Reis
To: list
Subject: Boot and Lisp for Axiom implementation
I see that there has been some effort invested in rewriting the
Boot codes in Lisp. I believe that is a fundamental mistake. Even
though Boot is a syntactic sugar over Lisp, it apears through
experiments I conducted here on (non-representative) sample that
students get quickly their mind wrapped around the Boot code than the
Lisp equivalent; mostly -- I suspect -- because of the structural
pattern matching, and structured Boot operators.
\start
Date: Sat, 27 Jan 2007 14:06:01 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: sayMessage
On Wed, 17 Jan 2007, Waldek Hebisch wrote:
| I personally do not like this design, but it is not clear if
| alternatives are better. I considered:
|
| - making a completly independent function hierarchy for translator
| - adding global flag tested by relevant compiler functions
| - using assignment to 'symbol-function'
| - mixture of all above
|
| First variant means significant code duplication. Second variant
| means that individal compiler functions would be cluttered with extra
| functionality which is unused during normal operation. Third
| variant is a slight improvement compared to current situation
| (would allow to restore normal operation when the translator
| has finished), but ATM I am not sure if gains would justify
| effort. Fourth variant IMHO would only add confusion due to
| inconsistency.
Any reason not to consider fboundp? Also I seem to remember Camm said
GCL has built-in autoload capabilities. Since we're (un)fortunately
deeply rooted into GCL, why not consider that?
We currently have at least two Spad parsers (and same for Boot). And
at least as many grammars (not always in sync). And least twice parse
tree processors. That is recipe for confusion. We should aim for
decreasing duplications.
\start
Date: Sat, 27 Jan 2007 21:48:43 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: sayMessage
Gabriel Dos Reis wrote:
> On Wed, 17 Jan 2007, Waldek Hebisch wrote:
>
> | I personally do not like this design, but it is not clear if
> | alternatives are better. I considered:
> |
> | - making a completly independent function hierarchy for translator
> | - adding global flag tested by relevant compiler functions
> | - using assignment to 'symbol-function'
> | - mixture of all above
> |
> | First variant means significant code duplication. Second variant
> | means that individal compiler functions would be cluttered with extra
> | functionality which is unused during normal operation. Third
> | variant is a slight improvement compared to current situation
> | (would allow to restore normal operation when the translator
> | has finished), but ATM I am not sure if gains would justify
> | effort. Fourth variant IMHO would only add confusion due to
> | inconsistency.
>
> Any reason not to consider fboundp? Also I seem to remember Camm said
> GCL has built-in autoload capabilities. Since we're (un)fortunately
> deeply rooted into GCL, why not consider that?
>
Could you elaborate? I do not understand how fboundp and GCL autoload can
help for Aldor translator problem.
\start
Date: 27 Jan 2007 15:46:14 -0600
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: sayMessage
Waldek Hebisch writes:
| Gabriel Dos Reis wrote:
| > On Wed, 17 Jan 2007, Waldek Hebisch wrote:
| >
| > | I personally do not like this design, but it is not clear if
| > | alternatives are better. I considered:
| > |
| > | - making a completly independent function hierarchy for translator
| > | - adding global flag tested by relevant compiler functions
| > | - using assignment to 'symbol-function'
| > | - mixture of all above
| > |
| > | First variant means significant code duplication. Second variant
| > | means that individal compiler functions would be cluttered with extra
| > | functionality which is unused during normal operation. Third
| > | variant is a slight improvement compared to current situation
| > | (would allow to restore normal operation when the translator
| > | has finished), but ATM I am not sure if gains would justify
| > | effort. Fourth variant IMHO would only add confusion due to
| > | inconsistency.
| >
| > Any reason not to consider fboundp? Also I seem to remember Camm said
| > GCL has built-in autoload capabilities. Since we're (un)fortunately
| > deeply rooted into GCL, why not consider that?
| >
|
| Could you elaborate? I do not understand how fboundp and GCL autoload can
| help for Aldor translator problem.
I was addressing the specific issue of ensuring that a function
is effectively loaded, and if not load it.
(2) -> if null? FBOUNDP('parseTransform)$Lisp then oldParserAutoloadOnceTrigger()$Lisp
Loading /usr/local/libexec/axiom/target/i686-suse-linux/autoload/parsing.
Loading /usr/local/libexec/axiom/target/i686-suse-linux/autoload/bootlex.
Loading /usr/local/libexec/axiom/target/i686-suse-linux/autoload/def.
Loading /usr/local/libexec/axiom/target/i686-suse-linux/autoload/fnewmeta.
Loading /usr/local/libexec/axiom/target/i686-suse-linux/autoload/metalex.
Loading /usr/local/libexec/axiom/target/i686-suse-linux/autoload/metameta.
Loading /usr/local/libexec/axiom/target/i686-suse-linux/autoload/parse.
Loading /usr/local/libexec/axiom/target/i686-suse-linux/autoload/postpar.
Loading /usr/local/libexec/axiom/target/i686-suse-linux/autoload/postprop.
Loading /usr/local/libexec/axiom/target/i686-suse-linux/autoload/preparse.
(2) ()
Type: SExpression
(3) -> null? FBOUNDP('parseTransform)$Lisp
(3) false
Type: Boolean
\start
Date: Sat, 27 Jan 2007 23:16:36 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: browser front end, statement of plans and progress
On January 27, 2007 4:13 AM Martin Rubey wrote:
>
> Dear Tim,
>
> Although I'm happy that you are working on the documentation
> issues, I must say that I'm extremely concerned about your
> approach to
>
> > 2) replace hyperdoc
>
> and, maybe most importantly, about our (i.e., mine and your)
> communication with respect to these things. I very much hope
> that I misunderstood you.
> ...
>
> > By design all of the C code disappears and all work is done
> > inside the lisp image.
>
> I dislike C and like Lisp, too. But I have the feeling that
> throwing away C code should not be a goal per se.
>
> I very much hope that I could make my concerns understood.
>
Martin, I think you should not be overly concerned about Tim's
proposal since it seems to me that there is near zero likelihood
that any of this work will ever be completed. On the other hand
it is highly discouraging to me to see that such a potentially
major contributor to Axiom development as Tim should continue to
so badly miss-direct his efforts. But we have had this sort of
discussion before :-( so let me continue in a more postive manner.
Personally I am very much in favour of Andrey's recommendation to
re-consider the use of TeXmacs as a front-end to Axiom. TeXmacs
has an enormous potential that is mostly unused by the current
Axiom interface. Allowing Axiom to work in a seamless worksheet-
type interface mediated by a mathematically literate document
processor that uses Scheme (a Lisp variant) as it's internal
scripting language seems like an obvious perfect match. And
TeXmacs has a respectable user base, some of whom might well be
motivated to help with improving the Axiom interface.
I should mention here also the Sage interface to Axiom. Sage
shares some of the goals of TeXmacs in as much as it attempts to
provide a uniform interface to a wide range of computer algebra
systems. Sage already supports a browser-based worksheet user
interface (called a Notebook) which allows Axiom (and many other
systems) to be used both "natively" and in Sage's "cooked" mode
which provides a uniform python object-oriented syntax and
programming language. Sage is being very aggressively developed
by it's designer (William Stein) and a small army of volunteers.
I think improving the current Axiom interface to Sage would help
to ensure that Axiom remains well represented in this new world.
Note: Most recently the Sage developers seem to be focusing on
documentation issues that are very close in spirit to the work
done by Ralf Hemmecke in ALLPROSE although with very different
tools.
\start
Date: Sun, 28 Jan 2007 02:27:48 -0600
From: Tim Daly
To: list
Subject: browser front end, statement of plans and progress
Interesting set of replies.
Ralf is concerned that we would not have API documentation,
which is quite reasonable. We extract the existing
documentation automatically so I don't believe there is any
difference caused by displaying this documentation in a
standard browser rather than hyperdoc. The documentation
strings are extracted by the compiler and should be available
from the database files or the running image if we so desire.
I agree that we ought to carefully study the API documentation
issue. Possibly we could adopt a new syntax similar to javadoc
that allows us to use existing tools. Failing that we could
probably dynamically generate API documentation at compile
time that would be properly hyperlinked and easy to display.
Waldek says: "X11 problem should be easy to solve..."
except that it is not. I have experimented with making
the graphics and hyperdoc run on windows, freebsd, and
the mac. Each one has had its own problems, windows being
the hardest. I did succeed in getting hyperdoc running on
windows but there is no chance the average user wants to
put up with the pain of installing and using it. And it
won't talk to sman so it has limited functionality.
"... use portable drawing library"... which is exactly the
plan. The graphics needs to be split into two parts, the
drawing algorithms and the drawing technology. The algorithms
need to be placed where they can be manipulated, rewritten,
and extended by spad code. The drawing technology needs to
be more portable. The most portable drawing technology I've
found uses <canvas> tags in a browser window. Write once,
draw anywhere, locally or over a network, windows, linux,
freebsd, or mac.
"...multithreading is available only in some lisps..."
depends on the granularity of the processes. I've looked
into this and SBCL multithreads on all platforms. I have yet
to try this with web connections but it does work otherwise.
And this assumes that you use threading rather than tasks.
It is possible to create a separate, generated lisp object
to handle each display task and start each one as a standalone
task in a separate image, dedicate to the single graph.
"Hyperdoc uses essentially _the same_ TeX notation as the book..."
It does? The book contains nothing about pages or buttons.
It says nothing about the requirements for free references
to prior values. Certain portions of the information are
derived from certain portions of the book and there is every
reason for this to continue. But I have seen no effort to
create whole new subtrees of hyperdoc pages. Trying to embed
flash, sound, movies, jpgs, pdfs, and links to external movies
cannot happen. Hyperdoc does not support pamphlet files.
All of this would require extensive programming. But everyone
has a free viewer on every desktop that supports all of this
functionality called a browser.
I agree that the graphics needs to be more portable, easier
to manipulate from spad, threaded or tasked in such a way
that it is responsive to zoom/translate/rotate/shade, etc.
I'm not sure that I agree about the exact syntax of the hyperdoc
files, however. The hyperdoc language was invented before URLs,
html, ajax, etc. and really limits what you can put on a page.
Plus it is a one-of-a-kind language which limits the number of
likely authors. Since writing documentation is vital this is a
huge limitation.
Andrey suggests that TeXmacs "...is a better alternative than using
a browser as a front-end...". I agree with this in theory but I'm
not sure it holds up in practice. TeXmacs has limitations (e.g.
displaying graphics) but that's only a minor issue. TeXmacs has
been available for at least 6 years and attached to Axiom for
about 4 years. Yet I know of no-one who actively uses it as a
front end for Axiom. I don't even see it show up when people
demo TeXmacs at conferences.
"...the current graphics has a good feature that I can interact
with a plot...", "...this is not possible in a browser." In fact,
it is possible in a browser (as of Firefox 1.5) which is the
piece I've been waiting for. I've done some experiments to
convince myself that it works. I've even see MS paint in a
browser (http://canvaspaint.org).
"...a close coupling between graphics and computations is very
valuable...". I want to be able to have a continuously varying
stream of information displayed as a computation proceeds. Or
I want to have a graph data structure drawn in real time as
the program manipulates the graph data structure (the krops
network at the center of the crystal)
"...but why a browser? Its connection to Axiom computation engine
is very week". Well, everyone has a browser, they know how to use
it and they would know immediately how to interact with Axiom.
It is possible to do things like "folding" (similar to mathematica
notebooks) without having special programs. It is possible to
connect locally or remotely with no visible difference.
"...if you are prepared to wait as long as for getting some responce
from google earth..". Actually I suspect that Axiom will be running
on the same machine as the browser in most instances. In that case
bandwidth is not an issue. As for CPU resources I can't seem to buy
a machine these days that has a single CPU, the very latest
machines are quad-core machines and I saw today that the next
Intel/AMD machines are 8-way processors. Multiprocess machines
will be common in the near future.
"...Javascript is 100-1000 times less efficient than C..."
This way lies a religious war. Believe me, I dislike Javascript
as much as everyone else but it works and it does what I need to do.
I've rewritten portions of Hyperdoc into Javascript functions and
it provides the machinery I need. C does not, so it doesn't matter.
"...TeXmacs can do everything hyperdoc does"? Really? Not that
I'm aware of. Hyperdoc embeds images and can communicate commands
to Axiom and then display the resulting images inline (and start
up a separate process if you click on the image). I have no doubt
that TeXmacs COULD do this but I do doubt that it is on anyone's
desk to make this happen in the next year.
"Also, re-coding hyperdoc pages to LaTeX should be easier than to
html..." If we ignore handling text, LaTeX and html are
worlds apart. Html handles user interaction for input and output.
LaTeX formats text and equations and the occasional picture. They
are not "either-or" choices and both can exist together.
"...It is easy to output Axiom expressions as s-expressions, and to
send them to TeXmacs, without losing any information about their
internal structure and semantics...". This can't be done. The
semantics of the parts of the expressions have machine-level
pointers to domain data structures which point to other domain
data structure which index into other domain data structures, etc.
Once the pointer leaves the Axiom image it is meaningless and all
of Axiom's meaning comes from the domain where the expression lives.
Thus it is not possible to export an s-expression with all of its
semantics intact.
"...but I'm against browsers...". See the Axiom mailing list archives.
I agreed with you two years ago. Bill Page convinced me otherwise and
I've been looking at a way to use browsers for a long time. With the
introduction of the <canvas> tag the last piece of the puzzle has
fallen into place for me. I'm still undecided about mathml but I've
seen some very pretty formula work in it so my opinion may change
as I learn more.
"...TeXmacs is free and available for all platforms..." but so is
Firefox.
Gaby writes "Qt is available under windows". There are several
approaches I've looked at in terms of portable graphics code.
The most promising approach was to use Tcl/TK. We had a bit of
discussion about this with Camm on the mailing list sometime
last year. I built a small Tcl/TK version of hyperdoc but could
not get it to run properly from GCL. I looked at Glade this past
summer and built a few hyperdoc pages. Glade can generate windows
for any platform from description files. But it also didn't work
well with lisp. I got a copy of Visual C++ and tried to build a
few native windows on Windows XP. That way lies madness. I used
an X11 emulation program on the MS window for X11. I've been
experimenting with different systems for the past year and none of
them have been sufficient, although it was a great learning experience.
Martin writes: "...Ralf has written an excellent environment for
literate programs...". Yes, he showed it to me in France and I'm
really quite impressed. I'm not sure what this has to do with
the front-end issues to Axiom, however.
"Some time ago I asked you whether asq could be used to fetch
the documentation information also dynamically...I faintly
remember you answered but I never heard any further response."
I put up a web page that used asq to provide access to database
information from the web and I believe I passed it on to Bill
Page for inclusion on the wiki. The details are likely in the
mailing list somewhere. The web page I built for you is at:
http://daly.axiom-developer.org/asq.php
"...I cannot find any sane reason to give up these concepts from
ALLPROSE and Hyperdoc..."? Somehow you see using a browser to
access information from a back end as implying that we have to
give up our programming tools. I'm not sure why these two things
seem to be related. The fact that Axiom uses a different front end
should have no effect on what tools you use to write programs.
"...Dynamic api-documentation is a must for me..." and is clearly
a requirement for any front end. Given that the browser front end
would be speaking directly to an Axiom image why do you believe
that we wouldn't have dynamic information? You show libdb.text
information and then claim that hyperdoc will not display it.
Is tex4ht the right tool? I have no idea as I have not tried it.
Supposedly noweb will also generate html. There are many migration
paths to think about and explore. If I knew the answers I'd be
writing production code rather than these many throw-away experiments.
Bill Page writes "...I think you should not be overly concerned
about Tim's proposal since it seems to me that there is near zero
likelihood that any of this work will be completed...". ummm, ok.
I'll accept that insult and move on.
"... as Tim should continue to so badly miss-direct his efforts..."
Before the first release of the Axiom source code I decided that
documentation, both of the existing code and the new code, the way
to interact with documentation, documenting the algebra hierarchy
and documenting the algebra theory were vitally important. Since
that time most of my efforts have been directed toward documentation.
Several years ago I recreated the original book and about 13 months
ago I completed and published the first volume of axiom documentation.
Most recently, and soon to be released, is a several chapter booklet
documenting the quaterion domain. I'm not sure what you think my
efforts are directed toward but I've been pursuing this goal for
years and plan to continue.
"..I am very much in favour of Andrey's recommendation to re-consider
the use of TeXmacs...". Axiom has been available for 5 years or so.
TeXmacs has also been available for that time. Both have been connected
for several years. Name 3 people worldwide who develop Axiom code on
TeXmacs. I'd bet you do not.
"...Sage supports browser-based worksheets...which allow Axiom...
to be used both "natively"..." and from this you conclude that
having a browser front end to Axiom is mis-directed?
Anyway, thank you all for the feedback.
\start
Date: 28 Jan 2007 11:43:03 +0100
From: Martin Rubey
To: Tim Daly
Subject: Re: browser front end, statement of plans and progress
Tim Daly writes:
> Ralf is concerned that we would not have API documentation, which is quite
> reasonable. We extract the existing documentation automatically so I don't
> believe there is any difference caused by displaying this documentation in a
> standard browser rather than hyperdoc. The documentation strings are
> extracted by the compiler and should be available from the database files or
> the running image if we so desire.
If this is what you intend, great. I did mention that I'd hope everything was a
big misunderstanding on my part.
> I agree that we ought to carefully study the API documentation
> issue. Possibly we could adopt a new syntax similar to javadoc that allows us
> to use existing tools. Failing that we could probably dynamically generate
> API documentation at compile time that would be properly hyperlinked and easy
> to display.
So, what's wrong with the conventions used by ALLPROSE (they come from AlDoc
and AldorDoc...) ? Furthermore, they are quite close to HyperTeX... What more
can you want? You can put everything (graphics, videos, text) in the api you
like, of course. LaTeX is quite flexible.
> "Hyperdoc uses essentially _the same_ TeX notation as the book..." It does?
> The book contains nothing about pages or buttons. It says nothing about the
> requirements for free references to prior values.
I'd be surprised if you could manage to create a (paper-printed copy of a) book
that contains buttons :-) But why shouldn't we use the same "language" for both
the browser and the book. I think, that's the spirit of HyperTeX. By the way,
MuPAD uses quite a similar philosophy.
> Martin writes: "...Ralf has written an excellent environment for literate
> programs...". Yes, he showed it to me in France and I'm really quite
> impressed. I'm not sure what this has to do with the front-end issues to
> Axiom, however.
I'm repeatedly saying that I only want *one* set of conventions for writing
documentation and code. And I'm absolutely convinced that this should be LaTeX
like. Ralf has shown that this can be done, in a very user friendly manner.
> "Some time ago I asked you whether asq could be used to fetch the
> documentation information also dynamically...I faintly remember you answered
> but I never heard any further response." I put up a web page that used asq
> to provide access to database information from the web [...]
But that's not what I meant with "dynamic". I meant (and I hope I explained)
that I want asq or (any hyperdoc replacement) be able to use freshly generated
databases. I like your web page very very much, I think it is a great proof of
concept.
> "...I cannot find any sane reason to give up these concepts from ALLPROSE and
> Hyperdoc..."? Somehow you see using a browser to access information from a
> back end as implying that we have to give up our programming tools. I'm not
> sure why these two things seem to be related. The fact that Axiom uses a
> different front end should have no effect on what tools you use to write
> programs.
Great. I was only afraid that you want me to write api documentation - possible
also other documentation, I did not understand that part - in a language other
than LaTeX, or with a set of conventions different from those used for the rest
of the documentation. If this is not the case, I'm entirely happy.
I think it's time to set a price again. I'll pay 100$ anyone who writes a new,
or modifies an existing program, that displays the documentation of a +++
environment (and only this bit of documentation) as generated by ALLPROSE, on
demand, i.e., using a web interface similar to that Tim provided.
To get started, do the following
----------------------------------------------------------------------
svn co svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/trunk
cd combinat/trunk/combinat
notangle -t8 Makefile.nw > Makefile
make VARIANTSTOBUILD=axiom
cd lib
for f in $(ar t libcombinatax.al); do ar x libcombinatax.al $f; done
for f in $(ar t libcombinatax.al); do echo ")lib $f" >> combinat.input; done
cd ../src
axiom
-- now everything of combinat is available. To generate a libdb.text say
)se co args "-O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y $AXIOM/algebra -i ../include"
)co csseries
----------------------------------------------------------------------
(very likely, there is an easier way to generate the libdb file.)
To explain the process a bit: (Ralf, please correct me if I'm wrong)
make VARIANTSTOBUILD=axiom
extracts using noweb documentation and code from the source files, for example
series.as.nw. All of the code and the api description (i.e., everything between
\begin{+++} ... \end{+++} ) is put into a file csseries.as.
")co csseries" is one way to extract the +++ strings and write them into
libdb.text.
The best thing would be, of course, if one could simply call tex4ht on the
individual +++ strings. One would have to write a suitable LaTeX preamble, of
course, that \usepackages the appropriate style files. However, I do not know
how hyperlinking will work then. (In fact, I don't even understand hyperlinking
within ALLPROSE, and Ralf begs me to read the documentation since a few
months...)
Maybe it also makes sense to run a preprocessor over the literate
program. I.e., to modify ALLPROSE so that preprocecessed LaTeX (for example
html) is put into a database. But I would like the other solution better.
It would already be a great thing if doc could be displayed without
hyperlinks. That shouldn't be too hard, I believe.
> Is tex4ht the right tool? I have no idea as I have not tried it.
PLEASE try it. It produces just wonderful results. I admit, though, that I
myself found it difficult to set up. However, I'm sure you'll get help if you
ask for it.
> Supposedly noweb will also generate html.
What? I thought noweb simply extracts code and documentation, thus preparing
for LaTeX / TeX and Aldor / SPAD / C / Perl / whatever ?
\start
Date: Sun, 28 Jan 2007 23:01:57 -0500
From: Bill Page
To: Tim Daly
Subject: RE: browser front end, statement of plans and progress
On January 28, 2007 3:28 AM Tim Daly wrote:
> ...
> Bill Page writes "...I think you should not be overly concerned
> about Tim's proposal since it seems to me that there is near
> zero likelihood that any of this work will be completed...".
> ummm, ok. I'll accept that insult and move on.
Sorry Tim, I did not mean any insult to you. I just think you are
being terribly unrealistic. If I had announced that I intended
to learn Ocaml and re-write all of Axiom in my spare time, and
someone replied: "Surely I must have misunderstood you!" then I
would expect a similar response.
>
> "...
> as Tim should continue to so badly miss-direct his efforts..."
>
> Before the first release of the Axiom source code I decided that
> documentation, both of the existing code and the new code, the
> way to interact with documentation, documenting the algebra
> hierarchy and documenting the algebra theory were vitally
> important. Since that time most of my efforts have been directed
> toward documentation. Several years ago I recreated the original
> book and about 13 months ago I completed and published the first
> volume of axiom documentation. Most recently, and soon to be
> released, is a several chapter booklet documenting the quaternion
> domain. I'm not sure what you think my efforts are directed toward
> but I've been pursuing this goal for years and plan to continue.
Great. I think your efforts to document Axiom are VERY worthwhile
and I appreciate all of the time and effort that you have put into
this. When I referred to miss-directed efforts, I meant things
like rewriting Boot and C source code into Lisp and combining
separate source modules into awkward single monolithic "volumes" -
time that could be devoted to documenting Axiom internals. After
all Tim, you are one of the only remaining vocal members of this
project who actually worked on the original Axiom project at IBM
and wrote some of this code.
I am not too excited by documentation for the quaternion domain
but it might have some value if it serves as a model that other
people can follow for documenting more Axiom's algebra. But the
problem here is motivating other people to do this sort of thing.
I don't see that happening at all and it worries me.
>
> "..I am very much in favour of Andrey's recommendation to re-
> consider the use of TeXmacs...". Axiom has been available for
> 5 years or so. TeXmacs has also been available for that time.
> Both have been connected for several years. Name 3 people
> worldwide who develop Axiom code on TeXmacs. I'd bet you do
> not.
The original Axiom interface for TeXmacs was written when Axiom
was a commercial product. I ported the NAG Axiom tutorial to
TeXmacs as one of the first things I did with Axiom and I wrote
a new Axiom interface for TeXmacs on Windows. There have been
several people asking about TeXmacs and Axiom since then, but
yes 3 or 4 might be the right number. I might use TeXmacs if I
found a need to actually use Axiom for some printed publication
but out of familiarity I prefer the Axiom Wiki (mathaction) web
interface for most things I want other people to see. For Axiom
development usually I use only Axiom and a text editor in a
console session.
The reason why I favour an effort directed toward improving the
existing Axiom interface for TeXmacs is a strategic one - I think
there are people who would be motivated to learn more about Axiom
because they like the idea of WYSIWYG mathematical document
processing with access to computer algebra tools. Some people
certainly learn about Maxima this way. I think the interest in
Axiom would be greater if the Axiom interface for TeXmacs was
better.
>
> "...Sage supports browser-based worksheets...which allow Axiom...
> to be used both "natively"..." and from this you conclude that
> having a browser front end to Axiom is miss-directed?
>
No I am still very much also in favour of the type of browser front
end for Axiom that Kai Kaminski worked on almost two years ago.
I do think a browser front end for Axiom is a good idea -
particularly if it scales easily from desktop to public web server.
My point in part was that this has already largely been done, at
least in so much as the Sage interface to Axiom exposes Axiom to
the Sage Notebook interface. None of this involved re-writing any
existing Axiom source code. I think it makes good sense to continue
to build on this work.
I definitely don't think it makes good sense for the Axiom project
to proceed in the manner outlined in your statement of plans. But
this is a volunteer open source project and you have your own
interests and agenda, so my opinions need not have much impact on
how you actually spend your time. Anyway I think you have already
done the greatest possible service just by making Axiom available
as open source. What's next is up to all of us.
\start
Date: Mon, 29 Jan 2007 00:06:29 -0500
From: Alfredo Portes
To: Bill Page
Subject: Re: browser front end, statement of plans and progress
> No I am still very much also in favour of the type of browser front
> end for Axiom that Kai Kaminski worked on almost two years ago.
> I do think a browser front end for Axiom is a good idea -
> particularly if it scales easily from desktop to public web server.
> My point in part was that this has already largely been done, at
> least in so much as the Sage interface to Axiom exposes Axiom to
> the Sage Notebook interface. None of this involved re-writing any
> existing Axiom source code. I think it makes good sense to continue
> to build on this work.
I do not know how many people in this list have used Axiom via the Sage
notebook. Like you said I think using their notebook is a better idea than
starting from scratch. Their notebook uses much of the AJAX magic that
Tim would like to have for Axiom. We could ask William for permission to
use it (not that is necessary given that is open source, but it is a good
gesture) and patch it for Axiom needs, just like Sage does with Pyrex.
I think given that Tim would like this by next year, this will reduce the
development time by months.
Other things then can be addressed is Martin's concern about the
+++ documentation. I also would like also to have this to create something
similar to javadocs or python style, in which you can get the api without having
to read the whole literate document, if want you want is just a quick
info. I know
the Sage notebook allows to display latex already but I do not know if it has a
good rendering. Also the d&d pamphlet feature can be addressed.
The link in the frontpage of MathAction:
http://sage-notebook.axiom-developer.org/106 does not point to useful
Axiom
examples like you had before, maybe you can fix this. Tim probably can look at
it, and see if this is what he would like to have. I think this work
could attract more
contributors.
Regards,
Alfredo
PS: On another note, with the help of Ralf's ideas, I started writing
a Gedit plugin
to allow Literate programming. Currently I have a basic prototype working:
https://alfredoportes.com/~alfredo/lp.png
You can click on a button and the documentation gets extracted and
compiled using noweb and latex. I plan to add also something similar
to what Bill has on MathAction to extract the chunks of code.
This is just a trial and error, but my final goal is to actually
write a plugin for Eclipse
to allow literate programming, so it feels natural writing a pamphlet
inside of it, without loosing the features provided by the IDE or
other plugins (auto compiling, class browser, etc).
\start
Date: 29 Jan 2007 11:18:19 +0100
From: Francois Maltey
To: list
Subject: Re: browser front end, statement of plans and progress
I use axiom in a emacs with an axiom-mode which accepts multilines commands
in automatics temporary files,
or in a xterm for short tests.
I don't use texmacs because
I prefer the << light >> emacs to the CPU-eater texmacs.
I'll use the sage interface iff it's possible to hide the sage interpreter.
I don't want to type
SageResustl = axiom ("axiomVar := sum (q^k, k=0..n)")
but only type axiomVar := sum (q^k, k=0..n) in sage interface.
I can't do exercices for my students in a xterm,
axiom in a xterm looks like mupad-light, it's not a great interface.
But the other systems (emacs, texmacs or sage) are possible.
I might use but I don't use the hyper-doc.
I prefer grep in the *.spad files
and find very precious short help after +++.
When I used mupad I got the list of all the mupad-functions and
it was easy to complete a function name or a domain by the [tab] key.
It was nice. My emacs interface for mupad get also the man-page in emacs
and could copy examples from the help to the session.
The sage project has very pretty draw abilities.
Perhaps it'll be possible to export from axiom list of points, surfaces,
curves and get beautiful plots thanks to sage.
I don't use plot functions in axiom because it's difficult to draw multiple
curves in the same window. I can't do
plot ([x^(0.5*k) for k=-4..6],color=[blue, red, black, ...])
Have a nice day !
\start
Date: Mon, 29 Jan 2007 17:35:28 +0600 (NOVT)
From: Andrey G. Grozin
To: Tim Daly
Subject: Re: browser front end, statement of plans and progress
On Sun, 28 Jan 2007, Tim Daly wrote:
> "...TeXmacs can do everything hyperdoc does"? Really? Not that
> I'm aware of. Hyperdoc embeds images and can communicate commands
> to Axiom and then display the resulting images inline (and start
> up a separate process if you click on the image). I have no doubt
> that TeXmacs COULD do this but I do doubt that it is on anyone's
> desk to make this happen in the next year.
There is some mis-understanding here. TeXmacs can display inline graphics
for quite some time, and interfaces to many computer algebra systems do
exactly this. TeXmacs can send commands to external programs. No need to
wait, all of this is available. So, I think, TeXmacs is just a better
hyperdoc than hyperdoc.
> "...It is easy to output Axiom expressions as s-expressions, and to
> send them to TeXmacs, without losing any information about their
> internal structure and semantics...". This can't be done. The
> semantics of the parts of the expressions have machine-level
> pointers to domain data structures which point to other domain
> data structure which index into other domain data structures, etc.
> Once the pointer leaves the Axiom image it is meaningless and all
> of Axiom's meaning comes from the domain where the expression lives.
> Thus it is not possible to export an s-expression with all of its
> semantics intact.
Well, of course, the *full* semantics of an expression only exists within
Axiom. But a straightforward s-expression can easily contain more
semantics than LaTeX of display mathml. What is "a(b+c)", for example - a
function with an argument or a product? These 2 cases should be typesetted
slightly differently (and TeXmacs knows that).
I don't say that the current TeXmacs-Axiom interface is good, because it
is not. Therefore, few people use it. On the other hand, the
TeXmacs-maxima interface is much better, and the number of users is quite
large (I know, because I get a lot of emails when a new version od maxima
breaks this interface; this happens regularly :-( I think that a new and
much better TeXmacs-Axiom interface can be produced by a fraction of
efforts needed for other kinds of interfaces, which re-invent more weels.
I started to do it some time ago (not recently, don't remember exactly
when). I only needed a little help. I posted some questions to this list,
and received 0 replies. Exactly 0. So I could not proceed :-(
An idea about graphics: why not use an existing powerful data
visualisation system instead of the current graphics viewer? Something
like ParaView, VisIt, or OpenDX. These systems are highly non-trivial, and
it would be a shame to re-implement a small fraction of their
functionality instead of just using them. And Axiom will just prepare data
files for them. They are all free, and available on many platforms.
\start
Date: Mon, 29 Jan 2007 08:03:27 -0800 (PST)
From: Cliff Yapp
To: Andrey G. Grozin
Subject: Re: browser front end, statement of plans and progress
> I started to do it some time ago (not recently, don't remember
> exactly when). I only needed a little help. I posted some questions
> to this list, and received 0 replies. Exactly 0. So I could not
> proceed :-(
Could you re-post the questions? It sounds like now might be a good
time to revisit those questions and see if we can get you some answers.
\start
Date: Mon, 29 Jan 2007 11:04:24 -0500
From: Bill Page
To: Alfredo Portes
Subject: RE: browser front end, statement of plans and progress
On January 29, 2007 12:06 AM Alfredo Portes wrote:
> ...
> The link in the frontpage of MathAction:
> http://sage-notebook.axiom-developer.org/106
> does not point to useful Axiom examples like you had before,
> maybe you can fix this.
Alfredo, thanks for noticing this change. The content of the online
Sage Notebook was modified after I added the link. I have corrected
it now so that people can see immediately how Axiom looks in Sage:
http://sage-notebook.axiom-developer.org/axiom
> Tim probably can look at it, and see if this is what he would
> like to have. I think this work could attract more contributors.
>
Agreed.
\start
Date: Mon, 29 Jan 2007 11:07:42 -0500
From: Bill Page
To: Francois Maltey
Subject: RE: browser front end, statement of plans and progress
On January 29, 2007 5:18 AM Francois Maltey wrote:
> ...
> I'll use the sage interface iff it's possible to hide the
> sage interpreter.
> I don't want to type
> SageResustl = axiom ("axiomVar := sum (q^k, k=0..n)")
> but only type axiomVar := sum (q^k, k=0..n) in sage interface.
>
Please see the examples at:
http://sage-notebook.axiom-developer.org/axiom
Feel free to modify it and create more examples and/or create new
notebook pages. But be aware that you are editing online, so other
people will see your changes.
I would be happy to answer any questions you have.
\start
Date: Tue, 30 Jan 2007 08:12:40 -0500
From: Cliff Yapp
To: Andrey G. Grozin
Subject: TeXmacs and Graphics
Andrey G. Grozin wrote:
> I started to do it some time ago (not recently,
> don't remember exactly when). I only needed a little help. I posted some
> questions to this list, and received 0 replies. Exactly 0. So I could
> not proceed :-(
Are these the emails in question?
http://lists.nongnu.org/archive/html/axiom-developer/2005-08/msg00229.html
http://lists.nongnu.org/archive/html/axiom-developer/2005-09/msg00076.html
> An idea about graphics: why not use an existing powerful data
> visualisation system instead of the current graphics viewer? Something
> like ParaView, VisIt, or OpenDX. These systems are highly non-trivial,
> and it would be a shame to re-implement a small fraction of their
> functionality instead of just using them. And Axiom will just prepare
> data files for them. They are all free, and available on many platforms.
This is a good idea. I think in theory the best possible visualization
system would need to be tied closely to the core system, but I certainly
agree that the ability to take advantage of these systems is desirable
both as a short term measure and as a longer term feature. I suspect
the primary difficulty comes from most of us not knowing how to get
started implementing such export abilities.
I know of those programs, but I don't know much about them. I have
installed ParaView and OpenDX in the past, but I have not done much with
them. IIRC ParaView and VisIt both use the VTK toolkit. I have heard
very good things about that toolkit and have wondered in the past if it
wouldn't be capable of some truly stunning 3D plotting, but the learning
curve to working with it always seemed a bit formidable, to say nothing
of linking it to Lisp. Those systems seem a little heavyweight for
simple plot display, but of course there are likely to be many other
applications.
There are other formants which would be useful. Gnuplot is an obvious
one, and I think Grace would be a useful target as well for 2D output.
There are others. Probably once one such interface is made more would be
reasonably straightforward, at least as far as simple export is concerned.
Cheers,
CY
|