<peeps[zen]>
i don't think i'ver ever seen a beer crate, must be a euro thing. i've seen egg crates though
<peeps[zen]>
er, i mean milk crates, yeah those are the ones
fling_ has joined #openscad
fling has quit [Remote host closed the connection]
fling_ is now known as fling
fling has quit [Remote host closed the connection]
fling has joined #openscad
ur5us has quit [Ping timeout: 244 seconds]
peeps has joined #openscad
peeps[zen] has quit [Ping timeout: 248 seconds]
gunnbr_ has joined #openscad
othx has quit [Ping timeout: 268 seconds]
gunnbr has quit [Ping timeout: 252 seconds]
othx has joined #openscad
califax has quit [Ping timeout: 268 seconds]
califax has joined #openscad
aiyion has quit [Ping timeout: 268 seconds]
GNUmoon2 has quit [Ping timeout: 268 seconds]
aiyion has joined #openscad
GNUmoon2 has joined #openscad
<J1A84629194>
teepee what parameters your beercrate needs? size (xyz) and grid (3×4)?
<teepee>
hmm, maybe: diameter, height, count ?
<J1A84629194>
diameter is the result from size and grid (and walls) , what does count count?
<teepee>
calculating the other way around would be much easier for the user, like I specify the battery parameters and the number I want to store
<J1A84629194>
good luck with count 7
<J1A84629194>
but sure i could just round up
<J1A84629194>
however if you say 24 question would be if you like 4×6 or 8×3 or a 5×5 with one open
<Scopeuk>
I think, diameter, x count y count would make a middle ground, we do use that style of crate of any glass bottles that go through logistics in the uk, be that milk or beer or "fancy" soft drinks
<J1A84629194>
so i think i need grid and battery diameter for a crate and h
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
J1A84629194 is now known as J1A84
<J1A84>
wouldn't it be possible that small like e-15 numbers are just rounded to 0 .. this is annoying and doesn't make sense as they result from floating errors but now prevent that if(x>=0) is working as these can be ±e-15
<Friithian>
isn't e-15 like… -12?
<J1A84>
e⁻¹⁵
<Friithian>
aaaaaah
<J1A84>
10⁻¹⁵
<Friithian>
OOOH SHORTCAPS E
<Friithian>
smallcaps?
<Friithian>
I wouldn't be surprised if something that small was rounded
<J1A84>
no it isn't which my conditions fail
<J1A84>
+make
teepee has quit [Remote host closed the connection]
<Friithian>
ooh you want it rounded
<J1A84>
smallcaps? .. i have them on my keyboard
<Friithian>
I need my coffee
<Friithian>
ᴱ
<Friithian>
make a round() function?
<J1A84>
console: ECHO: 2.88658e-15
teepee has joined #openscad
<J1A84>
yeah great so i have to put every variable into a round function because it could happen?
<Friithian>
every variable that could be some weird floating point
<J1A84>
which is every variable that is used in math when divided
<Friithian>
well I personally would rather my program not do weird math on things without me explicitly saying so I guess yeah you'd hvae to do that
<J1A84>
so if you have a cube und you substract two cubes (each ½ of the first) then you think it is great that the rest distance is something e-15 ?
<Friithian>
the math should work in a predictable way and not get rid of data
<J1A84>
if this is a pure programming language i would agree but scad is CSG so we are dealing with geometry that should not exist in that size
<Friithian>
and also where would this rounding occur? when ever math is done? before being passed to a function?
<J1A84>
for conditions like x>0 ? or if(x>0)
<Friithian>
I have no idea what the backside of openscad looks like but I dont think it would be too hard to add that in and compile it
snaked has quit [Ping timeout: 256 seconds]
<peeps>
J1A84: sounds like you should do if(abs(x) > epsilon)
<peeps>
wanting the core language to arbitrarily modify floating point values is not an acceptable solution
<J1A84>
https://bpa.st/JU3A this is just not hard for user that are not programmer
<J1A84>
-not
<J1A84>
it is not about changing the variable .. it is to change the conditional check
<peeps>
comparing fp values for equality has always been a fools errand
<J1A84>
it is very unlikely that someone is using e-15 numbers, but it is very likely they emerge
<J1A84>
peeps how would you check if there is place left after putting arbitrary boxes into a void=10; .. so i put in x=[10/3,10/3,10/3] and would like if they fit .. instead i get " no they overlap -8.88178e-16 " - this is just not userfriendly
<InPhase>
J1A84: You can just as likely get 1 + 1e-15 or 1 - 1e-15, so it's not just about the 0. But when you round values you throw off other calculations. For example, if you rounded to 1e-14 then your c2 would no longer be 0 either. :)
<InPhase>
Everyone goes through a period of wanting to redesign how floats work, thinking it's a bug or design flaw. But you're fighting against some universal fundamentals of finite representation in math. Floats do as well as any approach can do in general. You can only beat them in specific cases, and the solution that works there will turn around and fail in another.
<J1A84>
InPhase again this is not about rounding the values it is that when comparing them <>= if == it should add/substract epsilon of e-14 to accommodate the fp error
<peeps>
J1A84: i wouldn't ever try to check something like that
<InPhase>
Well you can write that comparator, but it will fail in the next case.
<J1A84>
peeps so you are not able to tell if boxes fit into a box? .. that would be poor
<J1A84>
we need some fuzzy logic here in scad
<InPhase>
J1A84: aover3 = 340/3; a = 340-aover3-aover3-aover3; echo(a);
<J1A84>
or at least a warning that you have numbers that are beyond precision
<InPhase>
J1A84: The 1e-14 comparison fails on this one now.
<Friithian>
let's just stop using floating point numbers
<InPhase>
J1A84: You can do a relative comparison. But the relative comparison on a is unpredictable, because a is a residue. The comparison really needs to be relative to 340 and 10, which are intermediate values in the calculation.
<J1A84>
3mf stores 1e-6 so use 1e-9 for comparison
<InPhase>
J1A84: The real answer is just never design floating point algorithms around equality.
<J1A84>
fine so tell me how do i find out if my boxes fit in or not?
<peeps>
i have no idea what the usefulness of checking "if boxes fit into a box" is. it's like you are asking "is it possible to split 10 into three parts?" um, sure
<J1A84>
at the moment i add up the box sizes and check if there is residue
<peeps>
keep raging against the FPU
<InPhase>
J1A84: Well you use < or <= for floats, not ==
<J1A84>
In Phase that is what i have done .. x<=0 but then it was e-14 bigger
<InPhase>
Then the correct answer is that you did not guarantee that it fits.
<InPhase>
Not even in the real world. :)
<InPhase>
Floating points represent real measured values. It's what they are built for.
<InPhase>
And, you know that when you print something it's not exactly sized.
<InPhase>
Thus if you really want something to fit, you'll use a clearance/tolerance value of some sort.
<InPhase>
On the other hand if you want something to be approximately a certain size, you use rounding.
<J1A84>
you would be right if these are separate objects and not one grid
<J1A84>
I can solve this problem but this is a bug in a software if you addressing people without having studied computer science
<Friithian>
well given the nature of openscad I would be surprised if someone using it didn't have comp sci experience
<J1A84>
Friithian you need to read more issue reports from people try to use it - Ü
<Friithian>
I avoid reading issue reports more and more unless they pretain to me. So much… stuff I cannot spend time dealing with
<InPhase>
If you want to do integer type math, on the other hand, keep integer values. 64-bit floats will never alter the residuals for integer calculations from -9007199254740992 through 9007199254740992, which is a pretty big range to work with. :)
<InPhase>
But dividing by 3 will break in every finite representation used, even calculating by hand, unless you a rationals type or work with fractions.
<InPhase>
You would need a number system with a base that has 3 as a factor to make dividing by 3 work, and there are no such number systems in prominent use.
<J1A84>
but if i calculate the difference of the two numbers i compare and set that in relation to the value of the number itself - it would be easy to see if the difference is generated by fp or not ..
<InPhase>
In fact, on any finite representation of digits you can only exactly represent divisions by values that share all prime factors with the prime factors of the representation base. This is fundamental and unavoidable. Use a base 210 number system for 2*3*5*7? Well, dividing by 11 doesn't work.
<Friithian>
don't do any divisions and just keep everything as fractions
<InPhase>
There is no relative comparison algorithm that works reliably in an automated way. I've tried writing ideal ones many many times. If you try yourself, you will eventually discover all the cases where it fails. :)
ghee has quit [Quit: EOF]
<InPhase>
The only way it can be done is to allow the user to specify the relative and/or absolute threshold for approximate equality based on problem domain knowledge and a decision about what they actually mean by approximately equal.
<J1A84>
i think it would be great if you check x>0 and get a info " x is just e-15 to big/small " that wouldn't break any calculation but reminds the user that there is his problem in the design
<J1A84>
so if a comparison is just met or fails by a fraction of the value that this is probably not wanted
<InPhase>
I've many times written in code things like a < 359.99999 I wouldn't want a warning on values just over that. I'm really trying to exclude 360. :)
<J1A84>
that is why i wrote info and e-5 is far from e-15
<InPhase>
That's more like 3e-8 for the relative difference.
<J1A84>
nobody would use such small values but they emerge from fp
<J1A84>
yes right but still several orders of magnitude away
<J1A84>
and the problem is that echo( 359.99999); is 360 so this makes it hard to find a problem
<InPhase>
That's because someone decided that no one really wants to see values like 359.99999 with floating points so this is confusing for users and the output should be rounded. So they rounded it.
<InPhase>
See how one round trips up the next issue? :)
<InPhase>
There's no general solution other than switching reasoning away from exact math toward math that works in finite representational systems.
<J1A84>
you do understand that only rounding the display but not the results is a very bad idea
<J1A84>
so at least you need to see what you are working with
<J1A84>
(and not needing a library for that .. )
<InPhase>
Yes, in my own display code I intentionally avoid rounding, for exactly this reason. Even std::cout and such round too much.
<J1A84>
so we already round things as only 16 digits fit in .. so we have errors around that .. so the error need to be lower than the rounding we use for the math
<InPhase>
BUT, the reason it's rounded here, and in so many other places, is under exactly the same philosophy as your desire to change what comparison means. :)
<InPhase>
And it all has a downstream price. If we change a == b to mean approximately, then a == b does not apply a-b is 0.
<InPhase>
s/apply/imply/
<J1A84>
if i have a .001 error i would use 0.01 for my math to ensure the error will not affect my results
<InPhase>
If we set a-b to 0 when it's approximately 0, then whatever threshold we use for that becomes the new accumulated error, and we just moved the precision errors up the chain to be larger.
<J1A84>
this is something very basic for every science experiment - so why is this not used here?
<InPhase>
It's the other way around in science.
<J1A84>
all calculation run with the same precision but comparison use a magnitude bigger
<InPhase>
In science you never round values during calculation or propagation, but you also keep track of the expected errors all the way along so you can use those to interpret what the results really mean, which is a value in a certain range.
<J1A84>
This is what i say .. know the error when comparison is done and calculate it within
<InPhase>
In most cases in 3D modeling that error is determined by something like a measurement one did with a ruler, or a printer's error on producing a particular dimension.
<InPhase>
So the floating point error is rarely the key error we need to compare against. That only happens in rare cases of dividing integers by non-powers of 2 and still trying to get them to work like integers. :)
<InPhase>
It just so happens, that's the scenario you hit here.
<J1A84>
i hit that quite often
<InPhase>
It's probably in the end an XY problem. If you start out assuming floats won't do that, you'll pick a different way to calculate the original X goal.
<J1A84>
and as roof fails with $fn>40 i really find it offensive that a comparison is so pedantic about an value that is barley detectable.. i mean /10 and the error would be 0
<InPhase>
If you want grids, for example, start with integers and work the other direction scaling in the end.
<J1A84>
The thing is not to find a solution .. The thing is to find the problem .. if there is no info that your math fails due to shortcomings of software. you are just so used to this that you can't imagine anymore how strange this is. And to argue " we round the numbers in echo to not confuse user" - Ü
<InPhase>
I think echo shouldn't do that. I'm with you there. I think echo shouldn't do that for the same reason I think comparison should not approximate. It always causes secondary problems when you try to patch up float behavior.
<InPhase>
Fixing floats to "do what I mean" is not a won't-fix in the end, it's a fundamentally-can't-fix. But it takes some diving into the details to really convince yourself of this. Every fix for case A breaks case B. Thus, the fixes need to be case by case.
<J1A84>
i can accept that the float problem should not be patched but a user info would be great to notice something fails/work just by the amount of a floatingP error
<InPhase>
That's really the same sort of thing. You'd get spurious warnings when nothing is wrong on that.
<J1A84>
I am sure you won't as this would mean your design is only working by chance. This is something we see with roof where a slight change causes "open mesh" or "skeletton error"
<InPhase>
You know, some of those problems are caused by the fact that inside the OpenSCAD code it rounds floats for geometries to snap them to a grid, which in turn is done because the CGAL library uses rationals instead of floats for calculations to avoid floating point error, making CGAL slower when it does that, and thus a decision was made long ago to snap geometry values to a rounded grid to reduce the size
<InPhase>
of the rationals. But these approximations assuming no one would ever go beyond those propagate upward sometimes, and consequently we get things that sometimes slip into user-space issues. At the heart of this is two issues, one being the assumption that a little rounding to small values would never disrupt what people are actually intending to do, and the other is CGAL writing algorithms to try to be
<InPhase>
"exact" instead of working with the slightly different rules of finite representational math. :)
<InPhase>
As I've been saying, it causes issues to refuse to work with finite representation under its different rules. But you're absolutely not the first person to try it or want it. We get problems all over from past people trying it.
RoyK has quit [Ping timeout: 252 seconds]
<InPhase>
(Got to run.)
To_Aru_Shiroi_Ne has quit [Remote host closed the connection]
ToAruShiroiNeko has joined #openscad
RoyK has joined #openscad
noonien has quit [Ping timeout: 268 seconds]
ur5us has joined #openscad
gunnbr__ has joined #openscad
teepee has quit [Remote host closed the connection]
SamantazFox has quit [Remote host closed the connection]
ghee has quit [Quit: EOF]
ur5us has joined #openscad
<teepee>
joseph_: there was a recent discussion on the timeline changes and my understanding that changes were only possible at the mid-term point, it's possible till the final submission starts
<teepee>
so we can see if that helps shuffling things around, if google gives that option this year for the first time, we might as well use it