Tags: robpike/ivy
Tags
ivy: add === and !== operators for non-elementwise comparison This has been brewing for a while. Now that OrderedCompare is in, it is easy to provide the approximate equivalent of APL Match and Not Match, here done with === and !==. These operators look at the operands as a whole, not elementwise, even when they have very different types. The functionality was already there for set operations, this change just makes them available directly to the user.
ivy: add a rudimentary tracing functionality to the interpreter Add a ")debug trace" special command to enable execution tracing. If it's set to 1, it traces calls to user-defined operators. If it's set to 2 or highter, it traces all operators. The output is very simple and can get noisy fast, but should still be helpful. I've wanted this for a long time. Internally, this required the type of the debug map to change from boolean to integer, but that makes no real difference outside, and not much inside. Example: % ivy )debug cpu 0 panic 0 parse 0 tokens 0 trace 0 types 0 For trace: 1 traces user-defined only, 2 traces all operators op fac n = n < 1: 1; n*fac n-1 )debug trace 1 fac 3 > fac (3) | > fac (2) | | > fac (1) | | | > fac (0) 6 )debug trace 2 fac 3 > fac (3) | > (3) < (1) | > (3) - (1) | > fac (2) | | > (2) < (1) | | > (2) - (1) | | > fac (1) | | | > (1) < (1) | | | > (1) - (1) | | | > fac (0) | | | | > (0) < (1) | | | > (1) * (1) | | > (2) * (1) | > (3) * (2) 6 op a gcd b = a == b: a a > b: b gcd a-b a gcd b-a 8 gcd 2 > (8) gcd (2) | > (8) == (2) | > (8) > (2) | > (8) - (2) | > (2) gcd (6) | | > (2) == (6) | | > (2) > (6) | | > (6) - (2) | | > (2) gcd (4) | | | > (2) == (4) | | | > (2) > (4) | | | > (4) - (2) | | | > (2) gcd (2) | | | | > (2) == (2) 2
ivy: protect random number generation with a mutex Because both ? and rand can do multiple calls to the generator to fill their values, there can be races running under pfor. Put a lock around access to the generator. Also simplify the mean/stddev test for rand, which is where this arose. Interesting that @ disables pfor.
ivy: add an operator, rand, for floating-point random numbers APL (or maybe just Dyalog) uses ?0 for a float in the range [0,1), which we could do but it's clunky. We also can't just do ?1.0 because numbers are reduced before hitting the operator: 0.5 becomes rational 1/2 and 1.0 becomes integer one. Instead, we add a new operator, rand, that behaves exactly like the roll operator ? but ranges over all floats in [0, n) instead of just integers. To get high-precision random floats, we create two integers with the size of the mantissa and divide them, rand()/2^floatPrec, to get a high-precision mantissa, then scale it appropriately. I doubt it's mathematically perfect but it seems pretty good; I included a test to show that it gives mean and standard deviations as expected. Fixes #167
ivy: allow matrix to be vector shaped when printing Long ago, that would never happen but recent changes have permitted more mixing of rank. Remove the error test in matrix printing to allow a matrix to have dimension 1. Also simplify the iota code a bit. Fixes #161
ivy: allow matrix to be vector shaped when printing Long ago, that would never happen but recent changes have permitted more mixing of rank. Remove the error test in matrix printing to allow a matrix to have dimension 1. Also simplify the iota code a bit. Fixes #161
ivy: faster implementation of factorial Gets about 2X; could do better if multiplication of large numbers in math/big used an algorithm better at large numbers than Karatsuba. 10X or more is possible. The idea comes from Peter Luschny, https://oeis.org/A000142/a000142.pdf. The reference implementation linked from there, in Go, is about 25% slower than the one here, which is interesting.
ivy: don't use int64 and float64 in time calculations Because we were using UnixNano, the range of times was limited to only a few centuries. Rewrite the code to keep the high-precision values all the way through, allowing us to calculate with times very far away from today.
PreviousNext