teepee has quit [Remote host closed the connection]
<JordanBrown[m]>
Stale, but: I don’t have an OpenSCAD handy to check the behavior of, but I would say that is_number(inf) and is_number(NaN) should both be true, because is_number tests the data type, not the value.
<JordanBrown[m]>
tcurdt: the -D option gives a line to add to the program and so can be used to call a particular module.
<InPhase>
Auctus: That looks like it will be a huge help.
<JordanBrown[m]>
-D ‘foo();’
<InPhase>
Auctus: I would love to see a remesh() built-in which calls this.
<tcurdt>
JordanBrown[m] oh! I thought it was just for variables! nice! thx!
<InPhase>
Auctus: We cannot and should not automate it, because one of the guarantees OpenSCAD typically provides is preserving edge quality. This will do things like disrupt edge quality in well-made designs. But there are also a very large number of designs where this doesn't matter, and where garbage data is the input. A very prominent case of this is stl import from non-manifold programs.
teepee has joined #openscad
<InPhase>
JordanBrown[m]: Well what is_num "should" do is report if something is a number... Currently it reports false for nan and true for inf, the latter of which is mathematically incorrect.
<InPhase>
This fails under the premise of doing what things say on the label.
<JordanBrown[m]>
Sounds like it’s behavior on nan is not what I would expect.
<JordanBrown[m]>
I do not think of it as a math operator but rather a programming operator.
<InPhase>
JordanBrown[m]: If it were actually specified as a type check, I could accept that if we labeled it clearly. But because nan and inf are opposite answers, we are in a state of nonsense.
<JordanBrown[m]>
Alas I would have to agreee.
<JordanBrown[m]>
What I expect is that it is like n instanceof number.
<InPhase>
Since we established the current behavior is only from 2019, it's probably not too late to fix it.
<JordanBrown[m]>
All that said, I am having trouble coming up with a use case where it would really matter to me.
<JordanBrown[m]>
Because either inf or nan would mean that I already have a bug.
<InPhase>
I see here 'pending outcome of the "is inf a number" discussion'
<InPhase>
Not sure where those discussions happened.
<InPhase>
Commit b57eded is "
<InPhase>
@MichaelPFrey
<InPhase>
change is_num(1/0) from false to true "
<InPhase>
So somewhere a discussion happened whre they explicitly decided infinity was a number.
<InPhase>
The original Michael Frey implementation was correct, setting inf to false.
<tcurdt>
JordanBrown[m] so it literally just adds that line and still calls the global code it looks like?
<JordanBrown[m]>
I don’t use that feature, but that is my understanding and what the implementation looks like.
<tcurdt>
bummer ... ok
<tcurdt>
that's also what it looks like here
<JordanBrown[m]>
Ah I did not understand exactly what you said. But yes, it is equivalent to adding that line to the end of the program.
<InPhase>
Doug and nophead chimed in to support infinity being a number, and thus it was deemed decided. Unfortunately, I completely missed this discussion. https://github.com/openscad/openscad/issues/1584
<JordanBrown[m]>
With a bit of magic about reassigning.
<JordanBrown[m]>
Inf is not exactly a number, but it is more of a number than nan is.
<InPhase>
I would have opposed that strongly. :)
<JordanBrown[m]>
Priming a max loop with -inf makes perfect sense.
<InPhase>
The arguments of both doug and nophead there are invalid because both nan and inf are valid inputs for all the functions they cite for inf.
<JordanBrown[m]>
I don’t know whether cube(inf) works but it would be cool if you could use it in difference and intersection.
<InPhase>
Yeah, that would be a handy special-case geometry.
<InPhase>
I approve of abstractions. I don't approve of calling them numbers. :)
<JordanBrown[m]>
That way lies thinking that empty strings are not strings, or that empty arrays aren’t a thing.
<JordanBrown[m]>
I think that “is x data type number” is a valid question, to which the answer for nan and inf should be true, and in addition there should be ways to ask “is this a nan”, “is this inf”, and “is this either nan or inf”. (Or negations of those tests, if you prefer.)
<JordanBrown[m]>
But since we have a legacy of is_number(nan) returning false… don’t know, don’t care a lot.
J228765 has joined #openscad
J2287 has quit [Ping timeout: 260 seconds]
<InPhase>
JordanBrown[m]: I could endorse turning is_num into a type check, and adding is_finite for the other check.
<JordanBrown[m]>
And there is the question of whether == works on nan and inf.
<JordanBrown[m]>
I would say that > and < should work on inf, though maybe not on inf<inf or inf>inf. But maybe not == and !=.
<JordanBrown[m]>
Maybe not in inf < inf and inf > inf.
<JordanBrown[m]>
Matrix seems to be eating my greater than and less than characters.
<JordanBrown[m]>
Test > and <
<JordanBrown[m]>
Test < and >
<JordanBrown[m]>
Hmm <foo> hmm
<JordanBrown[m]>
Sometimes stuff between less than and greater than is being eaten.
<JordanBrown[m]>
Foo<I>bar</I>baz
<JordanBrown[m]>
But sometimes < it is not > .
<JordanBrown[m]>
Anyhow you get what I mean.
<JordanBrown[m]>
My purist instinct says that equality comparisons involving nan and inf should be undefined, or maybe always false.
<JordanBrown[m]>
My pragmatic opinion based on implementing it that way once is that it is a pain in the neck and it is better to say that nan==nan and 123!=nan.
fling has quit [Remote host closed the connection]
<JordanBrown[m]>
Just ask anybody who used dBase III about blank dates.
fling has joined #openscad
<JordanBrown[m]>
Best to have the comparisons all be defined, and defined in a consistent way, so that sorting is defined.
Junxter has joined #openscad
<Auctus>
InPhase: this CGAL thing, alpha wrapping, it's not the same as decimation or simplifying a mesh, it's more like "hull()" but with concavity -- think of it as shrinkwrapping to various degrees of "tightness"
<Auctus>
vacuum sealing
<InPhase>
JordanBrown[m]: I was about to say we have all the equality/inequality checks set right, but in fact we don't. inf == inf returns true, which is wrong.
<InPhase>
JordanBrown[m]: However, I believe that one is baked into IEEE-754 as an error.
<InPhase>
So while still completely wrong, it's completely wrong in a standard manner.
<InPhase>
A proper equality check that handles infinities mathematically correctly emerges for floats with a-b == 0, so it is at least still accessible.
<InPhase>
JordanBrown[m]: As for the others < and > have clear definitions for infinities as long as one value is not infinity. inf < inf should be undefined however, for which the best bool result is to always default to false like with nans. Fortunately, this happens correctly here, even if for the wrong reason (because they are considered equal).
GNUmoon has quit [Remote host closed the connection]
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
GNUmoon has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
castaway has joined #openscad
TheAssassin has quit [Ping timeout: 255 seconds]
TheAssassin has joined #openscad
<J228765>
WARNING: cube(size=inf, ...) in file , line 1 That is why it is annoying that inf is a number .. you can't use it as number
<J228765>
JordanBrown
_xxoxx has quit [Remote host closed the connection]
_xxoxx has joined #openscad
<J228765>
great Prusa "the 3mf consortion member" can not generate previews from 3mf anymore .. Ü
teepee has quit [Ping timeout: 255 seconds]
teepee has joined #openscad
fling has quit [Remote host closed the connection]
fling has joined #openscad
KimK has quit [Ping timeout: 260 seconds]
KimK has joined #openscad
escobear has joined #openscad
gknux has quit [Ping timeout: 260 seconds]
escobear is now known as gknux
<JordanBrown[m]>
InPhase: I agree that those are mathematically correct results. I am not at all sure that they are pragmatically correct results, because they make things like sorting and trees awkward. They probably force people implementing those things to effectively implement their own comparisons for those values. Also they mean requiring primitive “is” operators to detect the special values and explaining to people why straightforward
<JordanBrown[m]>
comparison does not work. Summarizing, they are a pain in the neck for very questionable practical value.
<JordanBrown[m]>
J228765: I didn’t say that infinite cubes worked, only that they would be useful.
<JordanBrown[m]>
Infinitely long cylinders would be useful. Infinite spheres not nearly so much.
<J228765>
didn't say you did Ü .. infinite geometry is like those negative volumes
<J228765>
prusa uses them (afaik) in 3mf and they f'up all viewer
<JordanBrown[m]>
AFK for several hours and maybe several days.
<J228765>
hope nothing serious
<JordanBrown[m]>
No, travel.
Scopeuk has quit [Quit: Scopeuk]
Scopeuk has joined #openscad
<InPhase>
JordanBrown[m]: The really useful infinite primitives would be plane slices, cylindrical slices, conical slices, and arc slices.
<InPhase>
Combinations of those could make most of the sorts of infinite slices you would want.
<InPhase>
And I suppose arc slices you can compose out of plane slices pretty easily.
<InPhase>
So plane, cylinder, cone, which gets you into the infinite extent primitives of the 3 major coordinate systems.
linext has joined #openscad
fling has quit [Ping timeout: 255 seconds]
fling has joined #openscad
NogetDigitalt has joined #openscad
DigitaltNoget has joined #openscad
teepee has quit [Remote host closed the connection]