Re: Behavior of struct and single-precision floating-point
Hi Kevin, hi all, On Thu, Dec 09, 2021 at 09:40:51PM +0100, Alexander Burger wrote: > The conversion function can easily detect the type (short or big) when > converting to float, and overflow to bignum if necessary when converting back > to PicoLisp numbers. > > This should really be fixed ... I check it next weekend. Done! Now (version 21.12.12), 'native', '%@' and 'struct' accept bignums for floating point arguments, and overflow to bignums for large floating point return values. : (scl 16) (load "@lib/math.l") : (pow 2.0 3.0) # This worked before -> 8 : (round @) -> "8.000" : (pow 100.0 100.0) # This did not work -> 121421546958041957442493134746744949294176709095342291740583330369404881029347127449862957279318330932090828950478869943421594604148335480073467842242942440201823873880805647866312652703956229962072064 : (round @) -> "100,000,000,000,000,002,142,1546,958,041,957,442,493,1347,467,449,492,941,7670,909,534,229,174,058,3330,369,404,881,029,347,1274,498,629,572,793,1833,093,209,082,895,047,8869,943,421,594,604,148,3354,800,734,678,422,4294,244,020,182,387,388,0805,647,866,312,652,703,96" : (exp 200.0) -> 7225973768125748468397301945341163734494552068524857298000992785760626356404779312666861737888136036352 : (log @) -> 200 : (round @) -> "200.000" Also, it returns now 'T' for values too large to be represented as a floating point number (i.e. "infinite"), and 'NIL' for too small values. : (pow 1000.0 1000.0) -> T : (exp 1000.0) -> T Note that for the scale there is still a maximum of 18 (i.e. a short number for the specification 1.0). IEEE 'double' support only 15 digits anyway. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Behavior of struct and single-precision floating-point
On Sun, Dec 12, 2021 at 10:25:46AM +0100, Alexander Burger wrote: >: (pow 100.0 100.0) # This did not work >-> > 121421546958041957442493134746744949294176709095342291740583330369404881029347127449862957279318330932090828950478869943421594604148335480073467842242942440201823873880805647866312652703956229962072064 >: (round @) >-> > "100,000,000,000,000,002,142,1546,958,041,957,442,493,1347,467,449,492,941,7670,909,534,229,174,058,3330,369,404,881,029,347,1274,498,629,572,793,1833,093,209,082,895,047,8869,943,421,594,604,148,3354,800,734,678,422,4294,244,020,182,387,388,0805,647,866,312,652,703,96" Oops! I just found that this is wrong! The final dot and digits are missing. So there was a bug in 'format' for large fixnums 😨 I fixed it and released again :) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Behavior of struct and single-precision floating-point
Awesome, thanks! On Sun, Dec 12, 2021 at 9:25 AM Alexander Burger wrote: > On Sun, Dec 12, 2021 at 10:25:46AM +0100, Alexander Burger wrote: > >: (pow 100.0 100.0) # This did not work > >-> > 121421546958041957442493134746744949294176709095342291740583330369404881029347127449862957279318330932090828950478869943421594604148335480073467842242942440201823873880805647866312652703956229962072064 > >: (round @) > >-> > "100,000,000,000,000,002,142,1546,958,041,957,442,493,1347,467,449,492,941,7670,909,534,229,174,058,3330,369,404,881,029,347,1274,498,629,572,793,1833,093,209,082,895,047,8869,943,421,594,604,148,3354,800,734,678,422,4294,244,020,182,387,388,0805,647,866,312,652,703,96" > > Oops! I just found that this is wrong! The final dot and digits are > missing. > > So there was a bug in 'format' for large fixnums 😨 > I fixed it and released again :) > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Feature request - 'fill'
Hi Alex, I know I (ab)use 'fill' / 'macro' too much in my code, but I often want to insert (not splice) the result of some calculation. Would you consider a new '_' syntax within 'fill' forms? : (fill (1 2 _ (+ 1 2)) -> (1 2 3) This can currently be accomplished a few different ways : (let X (+ 1 2) (fill (1 2 X) 'X)) : (let @X (+ 1 2) (macro (1 2 @X))) : (fill (1 2 ^ (list (+ 1 2))) The first two are quite verbose for what is usually a simple or concisely expressed calculation. The last one is ugly. Thoughts? -Erik
Re: Feature request - 'fill'
Hi Erik, > I know I (ab)use 'fill' / 'macro' too much in my code, but I often want > to insert (not splice) the result of some calculation. Would you consider > a new '_' syntax within 'fill' forms? > > : (fill (1 2 _ (+ 1 2)) > -> (1 2 3) Hmm, I would not be very happy if we invent yet another special symbol, in addition to the existing '^'. This might even break programs already having data with '_' symbols. > This can currently be accomplished a few different ways > > : (let X (+ 1 2) (fill (1 2 X) 'X)) > : (let @X (+ 1 2) (macro (1 2 @X))) I suppose you mean (let @X (+ 1 2) (fill (1 2 @X))), 'macro' uses 'fill' internally but then immediately evaluates the result. > : (fill (1 2 ^ (list (+ 1 2))) So yes, these are the three variants we currently have for 'fill'. > The first two are quite verbose for what is usually a simple or concisely > expressed calculation. The last one is ugly. I agree with you. Though in reality we often have the desired values already in variables, so that explicit 'let's are not needed. But I also would like to have an elegant way to achieve what you described. > Thoughts? What about some middle way? We stick with '^' only, but make it behave more intelligent: 1. If the result of the evaluation is a list, we get the same result as now. 2. But if the result is an atom, it is automatically 'cons'ed into a cell. This would not break any existing programs, as atomic results were useless. So we would get : (fill (1 2 ^(list (+ 1 2))) # Current semantics -> (1 2 3) : (fill (1 2 ^(+ 1 2)) # New behavior -> (1 2 3) What do you think? ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Feature request - 'fill'
Hi Alex, We stick with '^' only, but make it behave more intelligent: > >1. If the result of the evaluation is a list, we get the same result as > now. >2. But if the result is an atom, it is automatically 'cons'ed into a > cell. > > This would not break any existing programs, as atomic results were useless. > > [...] > > What do you think? > Works for me! I also often want to use a returned list without splicing, which is another use I had in mind with the proposed '_', e.g. : (macro (2 4 _(mapcar '((X) (+ X 2)) (4 6 -> (2 4 (6 8)) but the better way to do that is probably : (macro (2 4 (^(mapcar '((X) (+ X 2)) (4 6) -> (2 4 (6 8)) Thanks, Erik
Re: Extending 'VIP' editor
Hi list,
The rabbit hole went pretty deep. Here's my current viprc:
https://gist.github.com/erdg/ebf4556382bc1bbbaf534c4ebd927322
It now contains a substantial "command language" for lisp code based on
the keys '(', ')', '@' and '#'. There's also a bunch of utility functions
that
make writing these kinds of things slightly easier. And automatically
generated docs / cheat sheet that's updated every time viprc is reloaded.
Definitely a bit overkill, it's about as many lines as the editor itself.
It was
fun to write though :)
The full command listing is here:
https://gist.github.com/erdg/fa263802cc7c1b3d6cbc9398e5a86b5e
(I think) the only key I've overwritten is '#' (search word under cursor
backwards).
It is available as '##' or '^'.
If you decide to try it, please note that it will generate a file
~/.pil/viprc-docs.
Press 'g?' to view this file in vip.
- Erik
