<jasom>
papertanuki: FWIW Model doesnt' contain an array, only pointers (the two are not always the same in C).
taiju has joined #commonlisp
icer has quit [Ping timeout: 264 seconds]
Lord_of_Life has quit [Ping timeout: 264 seconds]
Lord_of_Life_ has joined #commonlisp
Lord_of_Life_ is now known as Lord_of_Life
Guest-liao has joined #commonlisp
<papertanuki>
jasom: I know, but in this case Model has "dynamic arrays" in the sense that it stores the length and the pointer to the start of the array.
igemnace has quit [Ping timeout: 258 seconds]
igemnace has joined #commonlisp
papertanuki has quit [Ping timeout: 256 seconds]
random-nick has quit [Quit: quit]
aeth has quit [Ping timeout: 260 seconds]
aeth has joined #commonlisp
hineios has quit [Ping timeout: 265 seconds]
peterhil has joined #commonlisp
paper has joined #commonlisp
paper has quit [Client Quit]
zacque has joined #commonlisp
aeth has quit [Ping timeout: 258 seconds]
aeth has joined #commonlisp
<zacque>
Hi #commonlisp
nature has quit [Remote host closed the connection]
jealousmonk has quit [Quit: ERC (IRC client for Emacs 27.1)]
Nilby has quit [Ping timeout: 264 seconds]
<jeosol>
hayley: I would think its the version on gitlab
<jeosol>
I am not sure how updated the github one is. But last time, I had to clone from the gitlab repo
<hayley>
They seem identical, and this repo claims to be a mirror. Still. Thanks!
Guest-liao has quit [Ping timeout: 256 seconds]
<beach>
Good morning everyone!
Guest-liao has joined #commonlisp
winning-luser has joined #commonlisp
Bike has quit [Quit: leaving]
<jeosol>
hayley: that's great then i f they are same. I didn't check github them.
<jeosol>
beach: good morning
Guest-liao has quit [Ping timeout: 256 seconds]
akoana has quit [Quit: leaving]
semz has quit [Ping timeout: 252 seconds]
<opcode>
anyone here familiar with the parse-float library? I'm hitting what I assume is an IEEE 754 bug, where the string "8.78" parses to 8.7799997, but the string "9.78" parses correctly to the number 9.78. I'm on SBCL 2.1.9 on MacOS
<opcode>
actually 8.78 parses correctly, but 7.78 parses incorrectly. Typo.
<beach>
What makes you think it is incorrect?
<White_Flame>
opcode: probably a single-float vs double-float discrepancy
<opcode>
White_Flame: perhaps
<White_Flame>
in sbcl linux x64, with read-default-float-format as single, I get that discrepancy. With it as double-float, it prints 7.78
<opcode>
beach: I would assume that a string-to-number parsing library should faithfully reproduce the number represented in the string
<beach>
opcode: What makes you think it is not faithfully reproduced?
semz has joined #commonlisp
<opcode>
beach: are you trolling?
<White_Flame>
obviously, typing in 7.78 at the repl parses it as a single-float and prints it in the same 7.78 representation, so it's not a ieee 754 problem
<beach>
opcode: I haven't checked this particular case, but floats are not represented in decimal, so it is entirely possible that there is not an exact decimal representation for the input you are giving.
<White_Flame>
parse-float has a COERCE operation into the returned type, which is probably where the imprecision lies
<opcode>
look beach I can't tell if you're just trying to be irritating but I think you know what I meant. If you feed a parsing library a string with a number, it should give you that number. Not a different number. Unless you're suggesting SBCL can't represent the number "7.78"
<opcode>
White_Flame: thanks for actually helping, I was not aware of the read-default-float-format variable
<beach>
opcode: That's exactly what I am suggesting. Did you check that your input has an exact representation in IEEE?
<White_Flame>
there is no "that number". fp represents a range
<White_Flame>
however, most FP systems try to ensure that the rounding involved makes the read input match the output print
<opcode>
yes exactly
<White_Flame>
but I can guarantee you that it is not holding 7.78
<opcode>
i'm sure it isn't holding 7.78
<opcode>
but my point is that the result I get from the parse operation should be 7.78 because that's the string I fed in
<opcode>
irrespective of the under the hood details
<beach>
*sigh*
<opcode>
*sigh*
<opcode>
beach: I don't know who you are but you've been profoundly unhelpful so I'm going to add you to ignore. Go troll someone else.
<beach>
Wow.
<hayley>
*sigh*
<White_Flame>
parse-float just builds the number in a haphazard manner
<White_Flame>
there's also no paired printer for it to match its output
<White_Flame>
SBCL's reader appears to keep it as perfect rational, then coerces it into the final format
<White_Flame>
and COERCE goes through a lot of detail in the fp construction, with biases and whatnot, which matches its printer
pranavats has left #commonlisp [Disconnected: Replaced by new connection]
pranavats has joined #commonlisp
<opcode>
I set read-default-float-format to 'double-float but it's still outputting the wrong number. Interestingly read-from-string does it correctly irrespective of float format
<White_Flame>
it's not outputting the wrong number
<opcode>
sure it is
<White_Flame>
I don't think you're using the right terms in the right places, hence beach's objections
<opcode>
maybe
<opcode>
the condescention from him/her was still unwarratned
<opcode>
*unwarranted
<opcode>
what I'm saying is
<opcode>
if I parse the string "7.78" I expect to see the number 7.78 in my repl
<opcode>
I'm well aware of the limitations of representing infinitely many numbers in a finite number of binary digits
<White_Flame>
why would you expect that with a 3rd party reader?
<White_Flame>
again, parse-float does not have a matching printer
<beach>
I think opcode had better adjust those expectations, but since I am being ignored, it doesn't matter much what I think.
<opcode>
I guess because if I was the author I'd consider it a bug
<White_Flame>
different implementations' floating point storage (which might change with tagging strategies) and their printers could vary. Which one is "right"?
<White_Flame>
when using parse-float on different implementations with different printers?
<opcode>
I don't think it's an extreme position to suggest that the "right" result is the one that common sense would indicate is correct
<opcode>
especially since (read-from-string "7.78") does produce 7.78 in the repl
<White_Flame>
given the details of FP, yeah that is an unrealistic position
<opcode>
I guess we'll have to agree to disagree
<White_Flame>
again, the critical part is that you are not using a matched reader & printer
<White_Flame>
at the repl with SBCL's reader & SBCL's printer, those 2 are tuned to matched
<White_Flame>
*be matched
<White_Flame>
but 3rd party reader + implementation printer can easily mismatch
<White_Flame>
and again, 3rd party reader + 3 different implementations' printers, which should it match?
<opcode>
how did you determine that there's no matched printer?
<White_Flame>
does parse-float include a floating point printer as well?
<White_Flame>
but even if it did, it doesn't know the implementation representation. It's only using toplevel math functions, not anything to do with the actual bit representation, as the implementation would do in its platform specific code
<White_Flame>
now, there's lots of work out there in terms of carefully matchign input to output, if you control both ends, but I'm not sure if those have a singular solution
<opcode>
Well, I have the most experience in C#/dotnet and in that ecosystem Double.Parse() will give you consistent results across the two platforms I've had time to try while we've been debating this
<opcode>
and if it didn't
<opcode>
I'm confident it would be considered a bug
<White_Flame>
in terms of the actual meaning of single-flaot, double-float, etc
<White_Flame>
but I did point out some weakness in parse-float's assembly steps
<opcode>
right but again, and this is just me personally, if I released a library that dealt with implementation-specific code and there was divergent behavior, irrespective of whether it's sockets or floats or what have you, I'd still consider that a bug
<White_Flame>
but this falls within reasonable realms of floating point issues, again because it's not targetting (and cannot target) a specific storage precision & printer
<opcode>
so when I came here asking about it, to be met with smug superiority from beach, it really rubs me the wrong way you know?
<White_Flame>
your terminology was pretty far off
<opcode>
well that's my bad, then
<White_Flame>
and beach was giving you leading questions to realize those
<opcode>
we all are responsible for the words we use
<opcode>
no, beach was playing the "lol ur such a newbie" game
<opcode>
giving half-answers
<White_Flame>
I don't think he said anything inappropriate
<opcode>
cmon man. 7.78 is not the same number (in the mathematical sense, not the binary representation sense) as 7.7799997
<opcode>
so to go "hurr durr what makes you think it's not the same number"
<White_Flame>
and computers don't work with "numbers" in the mathematical sense
<White_Flame>
when it comes to fp
<White_Flame>
so of course it's lossy regarding precision
<opcode>
right and I alluded to that at the outset
<White_Flame>
but whatever, I don't need a play by play
<White_Flame>
the description of the problem was wrong
<White_Flame>
you're using a reader that was not developed in tandem with a specific printer
<White_Flame>
and as a library, as it really can't technically be done as such, has precision decisions that the printer doesn't expect
winning-luser has quit [Quit: zzz]
<opcode>
>the description of the problem was wrong
<opcode>
absolutely, but we don't always know what we don't know
tyson2 has quit [Remote host closed the connection]
<White_Flame>
hence the usefulness of leading questions to get you there
<opcode>
i guess we'll have to agree to disagree on the usefulness of such questions
<White_Flame>
but still, this is veering really off topic for a pretty strictly on topic channel
<opcode>
I can tell you in retrospect I would never have got there following beach's ego game
<opcode>
yes, let's drop it. I appreciate your help White_Flame
<White_Flame>
I fail to see how you came to that view
<White_Flame>
np
lisp123 has joined #commonlisp
Guest-liao has joined #commonlisp
<beach>
White_Flame: Thanks. I don't think I said anything in appropriate either.
<beach>
White_Flame: Since I am ignored, I can say that I don't think opcode was requesting matching input and output functions. I just think that opcode thinks that the input number has an exact representation in floating point and expect that exact representation to be output.
peterhil has quit [Ping timeout: 260 seconds]
aartaka has joined #commonlisp
remexre has quit [Quit: WeeChat 3.1]
remexre has joined #commonlisp
remexre has quit [Client Quit]
remexre has joined #commonlisp
Krystof has quit [Ping timeout: 260 seconds]
<beach>
If I am doing this right, the SBCL reader turns 7.78 into a number that is greater than 778/100, and I think SBCL has a good input algorithm, i.e. it creates the closest float possible. That would indicate that the parse-float library does not.
Qwnavery has joined #commonlisp
azimut has quit [Remote host closed the connection]
Spawns_Carpeting has quit [Ping timeout: 264 seconds]
azimut has joined #commonlisp
<beach>
This discussion reminds me of several incidents when we used Common Lisp in our teaching, and the students discovered that typing something like (+ 0.4 0.3) to the REPL doesn't give the answer 0.7. They were then very happy to announce that they had found a "bug in Common Lisp".
<White_Flame>
beach: yeah, parse-float coerces portions of the number to the target float type, then combines them with adds and multiplies. this compounds precision issues
gxt has quit [Ping timeout: 276 seconds]
gxt has joined #commonlisp
Qwnavery has quit [Quit: WeeChat 3.3]
<jasom>
It seems that if it used rational arithmetic instead it could avoid that problem
<jasom>
However it's not unusual to see string -> float conversions with an error greater than 1ULP
rotateq has joined #commonlisp
amb007 has quit [Ping timeout: 260 seconds]
<lisp123>
beach: You mentioned earlier one of the issues with a CL editor being that without multiple global environments, a crash in the code will cause the editor to crash. How did Lisp Machines or Hemlock (and others) handle this?
amb007 has joined #commonlisp
<beach>
White_Flame: Strange! If I wrote such a thing, I would make sure to use one of the known algorithms for creating the closest possible float.
<beach>
lisp123: I don't know. The issue is that current Common Lisp implementations prioritize performance over safety. I suppose the Lisp Machine didn't have to do that since they had a lot of hardware support. Don't know about CMUCL (which I believe Hemlock was written for), but it is entirely possible that SBCL has changed its priorities so that performance is more important. But i am just guessing.
<beach>
lisp123: But it's not related to multiple global environments like that. I am saying that, with multiple global environments done right, you wouldn't have a disaster if you (say) FMAKUNBOUND CAR. You would just consider that environment dead and create a new default one.
<lisp123>
beach: Ah thanks good to know. Oh I see, its from that perspective
<beach>
lisp123: And you would not run the editor in the same environment as you work, so you would kill your work environment, but not the editor.
<rotateq>
beach: This performance over-focusing seems to be a cultural thing. :)
<beach>
rotateq: Maybe so. What "culture" are you referring to here?
<rotateq>
Programming in general and "software development".
<jackdaniel>
I think that asserting that current implementations are more concerned about performance than safety may be a bit a stretch. if climacs signals error that is handler nowhere, you will end up in a debugger no matter how much attention you put to safety
<beach>
rotateq: Yes, I see. That sounds right.
<jackdaniel>
s/handler nowhere/handled nowhere/
<Qwnavery>
morning jackdaniel, beach
<rotateq>
often also too much business, unnecessary and inefficient planning and too less mathematics
<rotateq>
heyho jackdaniel. i should join #clim :)
<jackdaniel>
sure, go for it ,)
<beach>
jackdaniel: Right. The scenario I imagined was not when there is a defect in the editor, but when the editor is used in the same image as the application being written, and the programmer does something unsafe.
<jackdaniel>
opcode: if you expect exact representation of numbers in common lisp you may consider using ratios instead of floats
<lisp123>
I may ask this question on Stack Overflow. Because I'm curious that without being in the same image, it is not a trivial affair to transfer Lisp data to / from the image and capture all scenarios
<lisp123>
And being in the same global environment exposes the issues noted above
<beach>
lisp123: Hence the limitations of Emacs + SLIME for editing Common Lisp code.
cosimone has joined #commonlisp
<beach>
lisp123: But people seem to accept those limitations to avoid the scenario of an application crashing the editor. Shinmera, for instance, once said something like "I will never use an editor that runs in the same image as my application code". It is not an exact quote, but similar in spirit. And I can understand him, given how relatively easy it is to crash the Common Lisp implementation.
<jackdaniel>
beach: so you mean that some unrelated application sets (safety 0) (speed 3) and triggers some undefined behavior? I would classify it as the programmer being more concerned about performance than safety - the is neutral with this regard (i.e doesn't decide either way)
<jackdaniel>
and there is also restrict-policy in sbcl to mitigate even such scenarios
<beach>
jackdaniel: Sure, but it can happen as a result of a mistake too.
<beach>
jackdaniel: I am told that SBCL believes the programmer when a DYNAMIC-EXTENT declaration is used.
<beach>
jackdaniel: And I can very well see a programmer doing that by mistake.
<lisp123>
beach: Yes. Which makes me wonder what was done in the past. One _speculation_ I have is that they had a more advanced version of SWANK, but hopefully one of the lisp machine experts can answer it
<beach>
But, sure, it is quite possible to state that it is unwise to do things like that with an editor that runs in the same image as the application being developed.
<jackdaniel>
OK, I see your point; I think that the operator `the` is a good counter-example -- sbcl does trust the when safety is <=1 I think, while it doesn't on default settings
<beach>
jackdaniel: Yes, I see.
<lisp123>
(theoretically I don't see an elegant solution without multiple global environments)
<beach>
But those can be had. We just have to make it happen.
<lisp123>
Yup
<jackdaniel>
n.b (not an argument but an observation), sbcl has ext:*stack-allocate-dynamic-extent* to make it less trusting :) (i.e not trusting unless proven)
<jackdaniel>
when set to nil (although it defaults to t)
dickbar__ has joined #commonlisp
prxq has joined #commonlisp
pve has joined #commonlisp
rgherdt_ has joined #commonlisp
Odin-FOO has joined #commonlisp
jdz_ has joined #commonlisp
<dickbar__>
Just a remark: "7.78" should be printed as 7.78000000... (infinit number of zero's). You wil hear from me when i'am ready checking:-)
<beach>
I believe that's right. So that suggests that it was parsed incorrectly.
ski_ has joined #commonlisp
nckx_ has joined #commonlisp
bldr_ has joined #commonlisp
<dickbar__>
Still checking:-)
<jackdaniel>
"7.78" as a string should be printed as "7.78" or, aesthetically, as 7.78 - but it is not a number ;)
zacque has quit [Quit: Bye]
Odin- has quit [Ping timeout: 260 seconds]
jdz has quit [Ping timeout: 260 seconds]
nckx has quit [Ping timeout: 260 seconds]
ski has quit [Ping timeout: 260 seconds]
rgherdt has quit [Ping timeout: 260 seconds]
luis` has quit [Ping timeout: 260 seconds]
d4ryus has quit [Ping timeout: 260 seconds]
bldr has quit [Ping timeout: 260 seconds]
nckx_ is now known as nckx
Krystof has joined #commonlisp
d4ryus has joined #commonlisp
shka has joined #commonlisp
gaqwas has quit [Remote host closed the connection]
gaqwas has joined #commonlisp
luis` has joined #commonlisp
<saltrocklamp[m]>
does anyone here use the `parse-number` library? it seems to triggers some kind of deep internal error in both ccl and sbcl when attempting to parse a string with a literal tab character in it. e.g. in ccl i get "Error: The value NIL is not of the expected type UNSIGNED-BYTE. While executing: (:INTERNAL CCL::BAD-SEQUENCE-INTERVAL CCL::CHECK-SEQUENCE-BOUNDS)"
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
<semz>
not for me
<semz>
do you have an example string?
<semz>
saltrocklamp[m]: sorry, forgot to highlight
lisp123 has quit [Quit: Leaving...]
amb007 has quit [Read error: Connection reset by peer]
zacque has joined #commonlisp
amb007 has joined #commonlisp
<saltrocklamp[m]>
semz: just `(string #\tab)`
<semz>
ah, now I'm getting it too
<saltrocklamp[m]>
bummer. i guess it's a bug
amb007 has quit [Ping timeout: 260 seconds]
amb007 has joined #commonlisp
pve has quit [Ping timeout: 264 seconds]
amb007 has quit [Read error: Connection reset by peer]
kpoeck has joined #commonlisp
amb007 has joined #commonlisp
gaqwas has quit [Ping timeout: 260 seconds]
pve has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
<kpoeck>
::notify cracauer static-vectors loads fine in clasp
<Colleen>
kpoeck: Got it. I'll let cracauer know as soon as possible.
hendursa1 has joined #commonlisp
hendursaga has quit [Ping timeout: 276 seconds]
Qwnavery has quit [Ping timeout: 258 seconds]
Qwnavery has joined #commonlisp
<JeromeLon>
oh no, I missed one of my favorite descussions on binary numbers. I think a good answer was: 7.78 is 111.1100011110101110000101000111101011100001010001111010111000010100011110101110000101000111101011100001... in binary, which is truncated as specified by IEEE754 single precision to 111.110001111010111000010, which is exactly 7.7799997 in decimal.
<_death>
saltrocklamp[m]: it's not bummer, it's an opportunity (submitted a PR)
<beach>
JeromeLon: But the next higher single float is closer to 7.78 than the truncated one I think. So that means that PARSE-FLOAT truncates rather than returning the best approximation. Right?
<jackdaniel>
if ieee754 specifies truncating then it should truncate (well, not that common lisp tandard stipulates that its floats behave exactly like ieee754)
<jackdaniel>
marcoxa works on a spec for common lisp floats, it was mentioned during last (or one before last) els
<beach>
Does IEEE745 specify that it should truncate when a decimal representation is converted to a single float?
<jackdaniel>
s/on a spec/on a better spec/
<jackdaniel>
I don't know, I'm repeating what JeromeLon said "which is truncated as specified by IEEE754 single precision"
<beach>
But how is the original binary number obtained, and why was it truncated?
<beach>
There is no reason for that.
<beach>
That's just a choice by PARSE-FLOAT it seems.
<beach>
Whereas there are papers published on how to obtain the closest float for a particular decimal representation.
<JeromeLon>
IEEE745 specifies several rounding methods. Does it recommend one of them? I don't know actually
<beach>
JeromeLon: But isn't that beside the point?
<beach>
JeromeLon: There is no reason for PARSE-FLOAT to generate the original value that you showed.
<JeromeLon>
beach: yes, I agree with you, OC should ponder the source of the number 7.78. If it's a currency, it should not be parsed as a float.
<beach>
That's again a different issue.
<beach>
The best action on the part of PARSE-FLOAT would, in my opinion, be to return the best approximation. Not the truncation.
<beach>
And this opinion has nothing to do with IEEE truncation or rounding, nor anything about currency. Just how PARSE-FLOAT has decided to do it.
<beach>
JeromeLon: But, your remark certainly explains the observation by opcode.
<JeromeLon>
beach: I agree that the best approximation would be more correct. I disagree that it has nothing to do with IEEE 754 truncation or rounding. If IEEE 754 specifies clearly which rounding should be done, that PARSE-FLOAT should just do that.
<JeromeLon>
I can't find which rounding is recommended, though.
<beach>
JeromeLon: Where does IEEE say what rounding should be used when a decimal representation is converted to an IEEE float?
<beach>
Notice "when a decimal representation is converted", not "when a higher-precision binary representation is converted".
<JeromeLon>
beach: from wikipedia: "754-2008 requires correctly rounded base conversion between decimal and binary floating point within a range which depends on the format"
heisig has joined #commonlisp
<JeromeLon>
but I can't find an online version of 754-2008 to check what "correctly" means.
<beach>
In that case, truncation is not the right thing to do here.
<JeromeLon>
I agree. And it means that whatever 754 defines as the correct rounding is what PARSE-FLOAT should be doing
john-a-carroll has joined #commonlisp
<beach>
As far as I can tell, IEEE rounding has to do with the result of operations between floating-point numbers.
<beach>
But this is not such an operation.
lisp123 has joined #commonlisp
john-a-carroll has quit [Quit: Ping timeout (120 seconds)]
<beach>
The IEEE standard says "they shall use correct rounding" for the conversion, which sounds to me like "they shall return the closest floating-point number".
jdz_ is now known as jdz
<_death>
ieee754-2008 has a section 5.12 Details of conversion between floating-point data and external character sequences.. I'm not an expert on floats, but skimming it they talk about "correct rounding" which 2.1.12 defines as the rounding determined by the applicable rounding direction
<beach>
Hmm.
<_death>
4.3.3 says roundTiesToEven should likely be the default
<beach>
Oh, but that's only valid when the result is exactly in the middle between two values.
<JeromeLon>
which means round to closest and tie to even
<beach>
Yeah.
<_death>
right, so I'm guessing it also implies 4.3.1 round to nearest
<beach>
So if the next higher floating-point number is strictly closer to 7.78, then that next higher number should be returned.
<_death>
the definition of roundTiesToEven does not refer only to ties, it includes the notion of nearest
<lisp123>
flip214: I was thinking more broadly. I read it from time to time and there's a lot of wisdom in there
<_death>
there are too many.. just get the c.l.l archive and a good news reader (say gnus), sit back, relax, and spend a couple of months getting up to date
<lisp123>
_death: Good idea. Will see if I can put into my kindle..
<beach>
JeromeLon: I see now. Yes, that's the wrong algorithm for PARSE-FLOAT to use.
<pjb>
JeromeLon: if you're into high precision floating point computations, you should put (setf *read-default-float-format* 'double-float) in your rc file.
<beach>
JeromeLon: And it is entirely possible that the addition is rounded correctly while still giving that result.
<pjb>
JeromeLon: or explicitely set it in your programs.
<beach>
pjb: That's not what this is about. It is about a single observation by opcode.
<pjb>
The point is that 7.0 = 111000000000000000000000e-21 0.78 = 111110001111010111000011e-24 = 000110001111010111000010e-21 and 7.0 + 0.78 = 111110001111010111000010e-21 = 7.7799997
Nilby has joined #commonlisp
<_death>
JeromeLon: you know the single float is converted to double when passed to printf right?
<_death>
JeromeLon: then %f rounds it back
<JeromeLon>
_death: No, I didn't know, ok this test is wrong.
<pjb>
JeromeLon: in C, floating-point operations can convert to extended float first…
<JeromeLon>
pjb: "000110001111010111000010e-21" this looks truncated instead of rounded. 000110001111010111000011e-21 is closer
<_death>
JeromeLon: closer to what?
<JeromeLon>
to 0.78
frgo has joined #commonlisp
<_death>
JeromeLon: but you didn't give it 0.78, which is not representable as a floating point value
Oddity has quit [Ping timeout: 260 seconds]
<JeromeLon>
_death: 0.78 can be represented as either .07799997 or 0.07800002, I believe the debate is about which one is more correct.
<JeromeLon>
Sorry, I meant 0.7799997 or 0.7800002
<_death>
so, let's first agree that the addition is irrelevant
<_death>
(in this case)
<JeromeLon>
I disagree, but it's because I did not express myself clearly
amb007 has quit [Read error: Connection reset by peer]
<JeromeLon>
Legent: when summing 7 0.779999971389770507812500 (which is the single-float representation of 0.78), the 2 possible roundings (7.779999732971191406250 and 7.780000209808349609375) have the same distance to non-rounded value.
<JeromeLon>
*legend
<_death>
ok, and the first is even
peterhil has joined #commonlisp
<_death>
I didn't check the actual float value 0.78 gets converted to; only took the values discussed
icer has quit [Ping timeout: 264 seconds]
<JeromeLon>
so the conclusion is that PARSE-FLOAT doing a sum (integer part + decimal part) can introduce an error when the rounding of the decimal part changes in turn the rounding of the sum.
Guest-liao has joined #commonlisp
<_death>
correct
<_death>
(loop for x in (list (parse-float:parse-float "0.78") (+ 7.0 0.78) 0.78) collect (decimals:format-decimal-number x :round-magnitude -24))
<_death>
I mean 7.78 as the last element
<_death>
(and what's passed to parse-float..)
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
Guest-liao has quit [Ping timeout: 256 seconds]
Guest-liao has joined #commonlisp
tyson2 has joined #commonlisp
<rotateq>
this is why i like symbolic computing and exact arithmetic :)
Odin-FOO is now known as Odin-
<lisp123>
Actually on that, can I compare two uninterned symbols for equality via (equal (symbol-name #:me) (symbol-name #:you))?
<lisp123>
I presume EQL doesn't work for them?
<lisp123>
(sorry should be #:me and #:me to give T in the above example)
<beach>
The names are strings, so you can use whatever comparison on strings that works for you.
<Xach>
They are also string designators, so you can use string= directly also.
<pjb>
lisp123: (string= '#:me 'me) #| --> t |#
Bike has joined #commonlisp
icer has joined #commonlisp
<lisp123>
pjb: Thanks
<lisp123>
beach & Xach: thanks too
paule32 has joined #commonlisp
pve has quit [Ping timeout: 258 seconds]
pve has joined #commonlisp
igemnace has joined #commonlisp
gxt_ has joined #commonlisp
<saltrocklamp[m]>
<_death> "salt rock lamp: it's not bummer,..." <- that was quick! you found the issue?
<saltrocklamp[m]>
has anyone here used `check-it` before https://github.com/DalekBaldwin/check-it? something like `parse-number` would be a great place for property-based testing
<Nilby>
just add a few more to the 1d308 problems floating point has caused
nature has joined #commonlisp
rotateq has quit [Remote host closed the connection]
gxt_ has quit [Remote host closed the connection]
gxt_ has joined #commonlisp
dbotton has quit [Ping timeout: 245 seconds]
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
dbotton has joined #commonlisp
jhi has quit [Ping timeout: 258 seconds]
jhi has joined #commonlisp
Guest-liao has quit [Quit: Client closed]
flip214 has quit [Ping timeout: 264 seconds]
Guest-liao has joined #commonlisp
tyson2 has joined #commonlisp
rain3 has joined #commonlisp
hendursa1 has quit [Quit: hendursa1]
hendursaga has joined #commonlisp
rain3 has quit [Read error: Connection reset by peer]
hobo has joined #commonlisp
heisig has quit [Quit: Leaving]
icer has quit [Quit: WeeChat 2.8]
Guest-liao has quit [Quit: Client closed]
Cymew has quit [Ping timeout: 258 seconds]
<saltrocklamp[m]>
https://bpa.st/LRTQ does anyone see an obvious reason why the lisp version of my code (with sbcl) is not only ~5x slower than the python version of my code, but also isn't giving the right answers? the correct output numbers should be something like `249.9008` and `288.6628`
<saltrocklamp[m]>
any recommendations for a profiler would be appreciated too
hobo has quit [Quit: reboot]
rogersm has quit [Read error: Connection reset by peer]
<Bike>
if i had to guess, slow points could be parse-number and read-line
<Bike>
the latter of which you could deal with by reusing a preallocating string instead of allocating a new one each time read-line is called; maybe python is smart enough to do that for the "for line in" construct
mrcom has quit [Ping timeout: 245 seconds]
mrcom_ has quit [Ping timeout: 260 seconds]
<Krystof>
I think python defaults to double float; SBCL definitely defaults to single-float. That might be enough to explain the different answers
<Krystof>
well, actually: your wrapper around parse-number returns (values 0.0 nil) on a parse failure, but your check tests for the primary value being null
<saltrocklamp[m]>
oop, that was from an old version
<Krystof>
so you don't handle invalid lines correctly in your Lisp version
<saltrocklamp[m]>
yeah let me try fixing
<saltrocklamp[m]>
that said, i had a previous version of this that used READ + TYPEP to "parse" floats (returning NIL if it didn't actually read a float), and i think the answer was wrong there too, even when i set *READ-DEFAULT-FLOAT-FORMAT* to double-float
<saltrocklamp[m]>
Bike: i'll try `sb-sprof`, that looks nice and easy
<saltrocklamp[m]>
and i will try re-using the string, i assume you mean i should `setq`/`setf` it instead of using a step-form in `do`?
patrice has joined #commonlisp
flip214 has joined #commonlisp
ec has joined #commonlisp
dualinverter[m] has quit [Quit: You have been kicked for being idle]
kpoeck has quit [Quit: Client closed]
hendursaga has quit [Ping timeout: 276 seconds]
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
ec has quit [Remote host closed the connection]
hendursaga has joined #commonlisp
dec0d3r has quit [Remote host closed the connection]
<saltrocklamp[m]>
urgh, i ended up having to rewrite this with `prog`
<Bike>
by reusing the string i was thinking more like read-sequence
<saltrocklamp[m]>
that's much nicer pjb , i was wondering if there was a tidy loop version. Bike , wouldn't that cause problems if the current line is shorter than the previous line?
<Bike>
getting it right is more involved, yeah
slyrus has quit [Quit: Leaving]
<saltrocklamp[m]>
this is a great demo of advanced `loop`ing. setting `*read-default-float-format*` did fix the accuracy, but it's still ~7.5 seconds while the python version is ~1.5
<saltrocklamp[m]>
hard to tell which calls are slow, as opposed to just frequent. let me try the deterministic profile
<saltrocklamp[m]>
yep it looks like `read` is really the culprit, 0.000002 seconds per call at 2909618 calls, that's ~5.8 seconds spent on just `read`ing
tyson2 has joined #commonlisp
<saltrocklamp[m]>
i'm open to suggestions for how to fix this.. i admit i'm disappointed, i was expecting lisp to at least be comparable to python
zacque has quit [Quit: Goodbye :D]
<Bike>
how's parse-number compared to read? i'd expect parse-number to be faster
ec_ has joined #commonlisp
ec_ has quit [Ping timeout: 276 seconds]
ec_ has joined #commonlisp
<saltrocklamp[m]>
not appreciably faster in some of the tests i ran, but i can try again
<Bike>
hm. well that sucks.
<saltrocklamp[m]>
i'm not sure if it's possible to write the `loop` version using it
<saltrocklamp[m]>
weird that there's `parse-integer` in the standard but not `parse-float` - i saw some discussion about it above, maybe sicl will turn out to be the fast implementation :)
igemnace has quit [Ping timeout: 260 seconds]
<Krystof>
the more generic your parsing thing, the slower it is likely to be
<Krystof>
I'd start by trying to use parse-float, though I don't know how optimized it is
<Krystof>
read is a full parser; parse-number is presumably a limited tokenizer; parse-float will be even more limited
<Krystof>
I would also be a bit suspicious of the deterministic profiler; the overhead is substantial and subtracting the overhead off is not necessarily 100% correct
ec_ has quit [Ping timeout: 276 seconds]
rgherdt_ has quit [Ping timeout: 245 seconds]
<saltrocklamp[m]>
does sbcl have `parse-float`?
amb007 has quit [Ping timeout: 260 seconds]
amb007 has joined #commonlisp
<saltrocklamp[m]>
i thought only lispworks had it
<Catie>
It's a library, loadable through quicklisp
<pjb>
saltrocklamp[m]: now, reading in lisp involves decoding octet sequences from files, into text, sequences of characters.
Spawns_Carpeting has joined #commonlisp
<saltrocklamp[m]>
oh, the library. i was wondering if it would be faster than `parse-number`
<saltrocklamp[m]>
i can try it
<pjb>
saltrocklamp[m]: in C, and python does like C, one only processes the octets, and almost never decode them into actual characters.
<pjb>
saltrocklamp[m]: so called, "utf-8 octet sequences"…
<pjb>
saltrocklamp[m]: that's where a lot of time (and memory) is spent when reading in CL.
<pjb>
saltrocklamp[m]: if you want to attain the same I/O performance, you must read octets in CL as well.
<saltrocklamp[m]>
python 3 strings are sequences of unicode code points, by default the input encoding is utf-8. so it's definitely doing full string parsing in my example (although i could probably make the python version faster by dropping down to use raw bytes)
<saltrocklamp[m]>
and in fact i think the internal storage is utf-16 or something like that, so not only is it parsing utf-8 but it's also converting it to another format
<saltrocklamp[m]>
however it is written in c, and i'm sure it's been heavily optimized
<saltrocklamp[m]>
not sure if that's what you meant, or something else?
<saltrocklamp[m]>
(in python 2, strings were raw octet/byte sequences)
<pjb>
this is an intermediate solution: we still convert to string, but assuming pure ascii input (this could also be done with :external-format :us-ascii, but it is highly implementation dependent whether it's possible to set the external format of *standard-input*.
<pjb>
saltrocklamp[m]: no, copy-and-paste from my libraries.
<pjb>
we could avoid converting to characters (which in sbcl take 32-bit each), by processing the octets directly. The float parsing function would have to be changed to use vectors of octets instead of strings.
<saltrocklamp[m]>
is this slurping the entire thing into memory? i forgot to mention this earlier, but one of the other requirements was to assume that the data is "huge" to the point where it can't be reasonably loaded all at once
<pjb>
eg. testing for 48 instead of #\0 etc.
<saltrocklamp[m]>
i see, hm. i wonder if that's what `parse-number` is doing
<pjb>
saltrocklamp[m]: then yes, looping on reading a buffer with read-sequence, and processing the octets instead of converting to string would be best.
<saltrocklamp[m]>
i am curious what python, lua, and nim are doing that make this so much more efficient than whatever sbcl and ccl are doing
<pjb>
saltrocklamp[m]: I told you: they process octets, instead of characters.
amb007 has quit [Ping timeout: 252 seconds]
<saltrocklamp[m]>
i think i was confused before. you are talking about the number parsing part?
<pjb>
which, for a file that contains mostly 10, 43, 45, 46, and 48-57, let you avoid a lot of processing…
amb007 has joined #commonlisp
<saltrocklamp[m]>
`for line in sys.stdin` in python iterates over true unicode strings, not byte sequences. but it would make sense if e.g. `float(s)` operated on the underlying bytes of the string `s`
frgo has quit [Ping timeout: 258 seconds]
<saltrocklamp[m]>
your `contents-from-stream` function seems to implement Bike's suggestion to re-use the string
<pjb>
AFAIK, python keeps the string as a utf-8 sequence.
frgo has joined #commonlisp
<saltrocklamp[m]>
it's not utf-8 internally in cpython at least, they use some wider encoding in order to do string lookups in constant time
<saltrocklamp[m]>
i'll have to spend some time reading these code snippets, my understanding of how "streams" work in list is hazy still
<saltrocklamp[m]>
i do wonder about the memory allocation, i am trying to look at the generated c code from the nim version to see if that's what nim does
tyson2 has quit [Remote host closed the connection]
amb007 has quit [Ping timeout: 258 seconds]
tyson2 has joined #commonlisp
amb007 has joined #commonlisp
nature has quit [Quit: leaving]
<saltrocklamp[m]>
found it, but holy moly that's a complicated c program
tyson2 has quit [Client Quit]
Skyfire has quit [Quit: WeeChat 3.3]
tyson2 has joined #commonlisp
mrcom has joined #commonlisp
mrcom_ has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
ec_ has quit [Ping timeout: 276 seconds]
gaqwas has joined #commonlisp
caret has joined #commonlisp
igemnace has joined #commonlisp
attila_lendvai has quit [Ping timeout: 260 seconds]
ec_ has joined #commonlisp
mrcom_ has quit [Ping timeout: 260 seconds]
mrcom has quit [Ping timeout: 245 seconds]
mrcom_ has joined #commonlisp
mrcom has joined #commonlisp
akoana has joined #commonlisp
mrcom_ has quit [Read error: Connection reset by peer]
cosimone has quit [Quit: ERC (IRC client for Emacs 27.1)]
ec_ has quit [Ping timeout: 276 seconds]
mrcom has quit [Read error: Connection reset by peer]
mrcom_ has joined #commonlisp
ec_ has joined #commonlisp
ec_ has quit [Ping timeout: 276 seconds]
mrcom has joined #commonlisp
cage has quit [Quit: rcirc on GNU Emacs 27.1]
gaqwas has quit [Remote host closed the connection]
gaqwas has joined #commonlisp
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
mrcom_ has quit [Read error: Connection reset by peer]
lisp123 has quit [Quit: Leaving...]
caret has quit [Read error: Connection reset by peer]
kevingal has joined #commonlisp
tyson2 has joined #commonlisp
ski_ is now known as ski
James` has joined #commonlisp
mrcom has quit [Read error: Connection reset by peer]
<James`>
Hey I got a question and I read this chat is active
<James`>
Anybody know how I can write a defmacro within a defun? Similar to this post on SO, but for defmacros
<Bike>
you can use macro-function instead of symbol-function there, but you probably don't want to actually do this
<James`>
I see, I can try that. Yeah I wasn't sure if its the right way...
<Bike>
What are you trying to do?
molson has quit [Ping timeout: 252 seconds]
<James`>
So I am writing some tests (fiasco), and doing stuff like (deftest t1-fail () ....
<James`>
Now I want to automate the name generation, so I can write each test like a reader macro #T(...) and have the names automatically created for each
<James`>
So I just write the basic test, and I extract from it which function I'm testing and a counter for that function (stored in a hash table) to then build the deftest form
mrcom has joined #commonlisp
<Bike>
can you just do like, (defmacro my-deftest (&body body) `(deftest ,(generate-a-name) ,@body)), or what am i missing here
<Nilby>
Lisp seems like a drug that causes the human mind to create test frameworks.
<James`>
That's what I initially tried, but couldn't get it to work
<Bike>
what happened?
<James`>
It doesn't seem to create the test macro (e.g. I do my-test-1231 and I get an error 'No test ....)
<James`>
Whereas if I manually do it, it works. I think it may have something to do with interning symbols...
<Bike>
wait, okay, so then you need the name later?
<Bike>
i'm not sure i understand your goal here. You want nameless tests except you actually do need to know the name?
<James`>
Yeah I'm going to write all the tests in a file, so I need the names
mrcom has quit [Read error: Connection reset by peer]
<Bike>
okay, well how about you store the names somewhere. do (defvar *test-names* nil) and then (defmacro my-deftest (&body body) (let ((name (generate-a-name))) `(progn (push ',name *test-names*) (deftest ,name ,@body)))
<James`>
Thanks, I will play around with it, don't want to take up more of your time. I faced the same issue, 'no test ....' after running it, but I gotta figure this out for myself, sounds like its possible to do it the way you say and what I thought initially so its something else
<James`>
That's causing the issue
<James`>
Thanks Again
<Bike>
Good luck
mrcom has joined #commonlisp
<James`>
Cheers mate
James` has left #commonlisp [ERC (IRC client for Emacs 27.1)]
varjag has joined #commonlisp
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
kevingal has quit [Remote host closed the connection]
dec0d3r has joined #commonlisp
pve has quit [Quit: leaving]
mrcom_ has joined #commonlisp
<jcowan>
(= 8.7799997 8.78) => T because round to even, whereas (= 8.7800002 8.78) => NIL
nature has joined #commonlisp
aartaka has quit [Ping timeout: 245 seconds]
patrice has quit [Quit: Leaving]
kdlv has quit [Ping timeout: 264 seconds]
kdlv has joined #commonlisp
kdlv has quit [Ping timeout: 260 seconds]
icer has joined #commonlisp
varjag has quit [Ping timeout: 258 seconds]
tyson2 has joined #commonlisp
shka has quit [Ping timeout: 260 seconds]
kdlv has joined #commonlisp
icer has quit [Quit: WeeChat 2.8]
Skyfire has joined #commonlisp
taiju has quit [Ping timeout: 258 seconds]
taiju has joined #commonlisp
<JeromeLon>
jcowan: both return T for me with sbcl, ecl and clisp.
<jcowan>
ah, I had one too many 0s
<Catie>
Conversely, CCL returns NIL for both under FreeBSD with *READ-DEFAULT-FLOAT-FORMAT* set to DOUBLE-FLOAT