We could talk about a "verifyable" "determined" "world": causes could, would drop out. The seek for cause, begin could, would drop out;-)
Well, that list is a bit of a stretch.
After all, black holes, mesons, photons... are all part of specific theories with success in predicting criteria.
Black holes, or the nature of a "black hole" is a theory.
Dark Matter is also a theory.
Klingons fail Occam's Razor. Too complicated, too contrived.
But, I got to admit, I think Klingons are much more fun to watch. However, you give the Romulans short thrift.
If the Klingons are simple photons, the Romulans are like spinning neutrons travelling through the galaxy in a gravity wave hidden within the intergalactic Dark Matter from their homes in Black Holes.
Using my now legendary googling skills 😉, a search for "determined world" brings up "determinism".
Perhaps it is determinism to which you refer. It's difficult to tell from your sentence construction, so correct me if I'm wrong.
Determinism means that if things behave in a certain way at a time t, then the way things behave thereafter is fixed according to laws of nature that usually go unquestioned.
Determinism is deeply connected with our understanding of physics and its ambitions to explain the universe.
I read that determinism frequently fails in the theory of general relativity with its dynamic spacetime - just don't ask me to explain why and where!
Attachments
That is the problem with AI.... the paper I once wrote:
"How do we determine that a non deterministic system is functioning correctly?"
The answer is at first blush statistical but we can apply some limits to the heuristics to bind the solution to within a valid range.
Trust me, solving problems this way requires lots of computing.
@Galu
Think.... it's inductive logic. The decision making gets into a node, with more than one path. So it will take a path based on some heuristic.
If that path doesn't converge to a solution then it has to come back to that node and take another path. And so on.
To give you an idea. I dealt with such algorithm in the 90s. We could determine nonconvergence when the denominator became 0. So in order to prevent a "division by 0" error, which normally crashed the entire machine, not just the process ( floating point processor here ), we had tons of "defensive code"... conditionals that would check that the denominator was NOT 0 and then traverse a whole bunch of "return ERR" conditions as the algorithm unwound itself to the last node that was processed.
But our top of the line Sun Microsystems cores were taking 28 hours to process 24 hours of data... so we decided to remove all of the defensive code, implement a trap for the DIV-0 interrupt, and come out with some kind of checkpointing mechanism. In essence, what I did ( I designed and wrote this ) was to implement a checkpoint at every node... leaving a bread crumb so we knew the state at the node. If we took a DIV-0 interrupt we'd just continue at the latest checkpoint and we took a different path from the last time around.
I was able to take those 28 hours down to 18!
Sure, today our cores are much faster... BUT... we are tackling more complex, more dynamic solutions. So, the demand for computing is definitely there.
And just to blow your mind, if you're following, most of this is floating point calculations! You got to take into account accuracy and errors, the precision of the calculations and added errors... so equality is never exact! Floating point arithmetic is very cumbersome!
Think.... it's inductive logic. The decision making gets into a node, with more than one path. So it will take a path based on some heuristic.
If that path doesn't converge to a solution then it has to come back to that node and take another path. And so on.
To give you an idea. I dealt with such algorithm in the 90s. We could determine nonconvergence when the denominator became 0. So in order to prevent a "division by 0" error, which normally crashed the entire machine, not just the process ( floating point processor here ), we had tons of "defensive code"... conditionals that would check that the denominator was NOT 0 and then traverse a whole bunch of "return ERR" conditions as the algorithm unwound itself to the last node that was processed.
But our top of the line Sun Microsystems cores were taking 28 hours to process 24 hours of data... so we decided to remove all of the defensive code, implement a trap for the DIV-0 interrupt, and come out with some kind of checkpointing mechanism. In essence, what I did ( I designed and wrote this ) was to implement a checkpoint at every node... leaving a bread crumb so we knew the state at the node. If we took a DIV-0 interrupt we'd just continue at the latest checkpoint and we took a different path from the last time around.
I was able to take those 28 hours down to 18!
Sure, today our cores are much faster... BUT... we are tackling more complex, more dynamic solutions. So, the demand for computing is definitely there.
And just to blow your mind, if you're following, most of this is floating point calculations! You got to take into account accuracy and errors, the precision of the calculations and added errors... so equality is never exact! Floating point arithmetic is very cumbersome!
I tried to explain it carefully so that a reasonably intelligent person would understand it.
I know Scots can be intelligent... (*) my Linn LP12 is made in Scotland.
I had to take the design through a peer review... trust me, my managers and peers in that project were middle aged oriental-american ladies ( engineers ) and they were tough as nails with their questions. I wanted to dispose of them in a very prejudiced manner.... " I'm throwing pearls in front of swine!! "
But afterwards they signed off on the design, gave me a "good job" sign, and we went for lunch at a local Hunan restaurant ( this was while working at a very well known Pasadena Lab ) down La Cañada.
(*) hehehehe...
Attachments
Last edited:
It is always satisfying when you get such a speed up, I have 2 i remeber fondly. 1, a small piece of code optimized in assembler (really early 80286), and gained orders of magnitude improvement.
And the other was a HUGE (object oriented) spreadsheet where i was coached by an accountant exactly how to do a forcast to spec tha passes muster by those types. He had me implenent a scaler object for each month. So a large number of tables with 120 active single cells. When i was freed from him, and with the same exact logic converted to 12x10 matrices and also gained order sof magnitude (from like an hour, to minutes (68020).
I wrote a set of 32 bit floating point algorithms in 6809 assembler. Fun.
dave
@planet10
Yeah, those accountants.
I had a gig once at Teradata. We were doing the Unix port. So I took the SQL course we offered our customers.
Looking through the syntax, I figured out how to optimize it... so there was this example SQL report that took like a minute to run. I optimized it to under 750 msecs.... mosty by using those temporary tables as local storage "variables". SQL is actually an interesting thing if you look at it as a "language" not a "script".
So, the next day I went into the class and I demo'd it. The teacher was impressed.
The rest of the students.. you now, the clip on tie polyester "business programmers" didn't care. One of them said that if the reports ran under 10 minutes people were happy so why think about it?
I didn't last much doing SQL support.
...
I never touched the 6809, I touched the 6502, Z80, 8086, 6800, 68000, etc... Motorola did have excellent processors. Until ARM.
Yeah, those accountants.
I had a gig once at Teradata. We were doing the Unix port. So I took the SQL course we offered our customers.
Looking through the syntax, I figured out how to optimize it... so there was this example SQL report that took like a minute to run. I optimized it to under 750 msecs.... mosty by using those temporary tables as local storage "variables". SQL is actually an interesting thing if you look at it as a "language" not a "script".
So, the next day I went into the class and I demo'd it. The teacher was impressed.
The rest of the students.. you now, the clip on tie polyester "business programmers" didn't care. One of them said that if the reports ran under 10 minutes people were happy so why think about it?
I didn't last much doing SQL support.
...
I never touched the 6809, I touched the 6502, Z80, 8086, 6800, 68000, etc... Motorola did have excellent processors. Until ARM.
Last edited:
Aside:
Another "section" of "universe":
Who of us "analog" "electro-beings" can actually "digital"? Did not need a translator, for example, to view and listen to pictures or music from DVD or CD;-?
Another "section" of "universe":
Who of us "analog" "electro-beings" can actually "digital"? Did not need a translator, for example, to view and listen to pictures or music from DVD or CD;-?