Anyone here ever try using this for only place and route, while sticking to the proprietary tools for synthesis and bitstream generation? I'm honestly not even sure how you'd start (generate xdc and edif in vivado, convert to more common formats, and somehow get timing information?).
I get the impression a lot of emphasis is put on bitstream generation when it comes to open source fpga stuff. However, it seems like that's probably not where the real gains are for build time in any production system. Especially since there's no OSS supporting bitstream generation for the highest end boards anyway.
I agree it would be great for users to be able to mix and match EDA tools, but EDA tool vendors seem to disagree, and consider the state of poor interoperability among EDA tools as a nice barrier to entry. As far as I can tell open source tools work on bitstream generation because it is unnecessarily painful to interoperate with proprietary tools.
How do you want to do place and route for the high end boards that are not open/reversed anyway?
Related to the gains, I don't think bitstream generation is the biggest emphasis, its just a no-brainer after you have everything reversed and can do place&route in OSS.
With all the discussion here about alternative programs to make vector graphics for mathematical figures, I'm a little surprised no one has mentioned Ipe (https://ipe.otfried.org/), given it's far and away the most popular tool in my field (and has good native support for LaTeX expressions).
It certainly doesn't have all the features that Inkscape supports (although it does have quite a lot of features), but the features it does have are implemented with a heavy emphasis on ease-of-use. It's sometimes easier to brainstorm within the program than on paper.
It's also plenty easy to add useful plugins in Lua: At one point I coded a plugin to check if a diagram of a graph contained a Hamiltonian cycle (by calling an external C++ program I wrote that used simple backtracking). I was able to very quickly experiment with which of my small graphs and modifications to said graphs ended up having Hamiltonian cycles, and was able to narrow down some useful features to think about.
As someone who likes the idea of and quality of images that TikZ produces but not how obtuse it is, I've done a fair amount of research into this space at times. However, I've never heard of Ipe. Even if I had, I'm not sure I'd use it. The material is basically devoid of examples. How does one learn how to use it?
I work mostly on computational geometry and graph algorithms, and some related things (although I certainly don't have a very long list of publications). Ipe is written entirely by one person (Otfried Cheong), who works on a lot of computational geometry, which is likely part of why it's most well-known among this group. I've used Ipe for every diagram in every paper I've ever published, and I used them for all the figures in the slides of a course I taught a couple years ago. Clearly I'm a bit biased, but having used TikZ a small but painful number of times during my undergraduate degree, I'd be more than happy if I never have to work with it again.
Like everyone else I know, I learned Ipe through trial and error, with a handful of little tidbits of advice. 90% of the functionality you will use is quite intuitive and right there on the interface if you hover over things (and all the tools also have keyboard shortcuts of course). Some of the tips I've given/been given over the years that are less intuitive are:
- You can save directly in PDF and re-edit a PDF saved with Ipe. This is very helpful for a LaTeX project, since PDF files are very easy to import (even ones with multiple pages).
- When you import into a LaTeX project, the dimensions of the figure will be cropped to the dimensions of the actual content (this may be obvious to some, but it wasn't to me).
- You can edit the alignment of text (and other various hidden options) by right clicking on objects in select mode.
- The different snapping modes are probably the killer feature of Ipe. You can snap to the intersection of curves, to the vertices of polylines, and much more. Between the intersection snapping mode, circle tool, and line segment tool, you can technically perform any compass-ruler construction you want from Euclidean geometry (with has been useful a handful of times for me surprisingly).
- Selection of objects is a bit funny (but often useful): If you select from top-left to bottom-right, then you will only select things your selection box fully encapsulates. If you select instead from bottom-right to top-left, you will select anything your selection box intersects.
- Writing extensions and editing configs (incl changing page dimensions, colour palette, text size palette) is unfortunately quite painful, and I can only recommend digging through the examples. I believe there is documentation somewhere, but I found it less than helpful.
- You can edit the underlying points of any curve you place after the fact by using the "edit" option in the right-click menu.
- In order to use the regular k-gon "ipelet" (under ipelets->goodies IIRC), you need to have a circle present first (which you can of course delete afterwards). Ipelets are the mechanism by which you can program functionality with Lua, and this is probably the one I use the most (it comes built in with the program).
In my personal opinion, the only major weak point of Ipe is how annoying it is to rotate things (to the point where I often prefer to redraw things in rotated form, unless it's quite complex). To do this you need to very carefully select a pivot point type and a rotation type through the right-click menu. You also have to be very conscious of snapping as you perform the rotation.
Agreed. IPE is far far superior to Inkscape for mathematical diagrams. Honestly Inkscape is rather painful to use just for arty stuff. Using it for precise diagrams with maths labels sounds downright masochistic.
In my limited experience trying both on a couple CTF problems this last year (although having used Z3 a plenty for years before that), they're not even in the same ballpark. CVC5 is ridiculously good.
I do recall that for real number theory, CVC4 and Z3 have very different models though. I don't recall which one uses which model though, and I'm not sure if CVC5 uses the same model. I don't use either of them for real number arithmetic anyway.
Is the beta testers community invite-only?
Also, if the system you've built is really usable for trading, is it not more profitable to simply use it internally and trade your own capital? Have you tried to do that?
Layman here but I believe even a wonderful algorithm requires constant babysitting (as to not accidentally blow up your account via a bug) and the algo may only have an edge for a limited time at which point you need to figure out a new edge for your algo or develop a new one all together which could takes weeks or months. OP has chosen to sell shovels for the gold rush and make some passive income rather than do the constant, back breaking work of digging for gold.
You may be interested in Mahaney's Theorem (https://en.m.wikipedia.org/wiki/Mahaney%27s_theorem), which 'answers' a special case of this: If by vanishingly small you mean polynomial size, and you also assume Alice has an algorithm that can distinguish the two subclasses of graph isomorphism, then P=NP if Alice has these facts. By 'distinguish', I specifically mean that Alice has a polynomial time algorithm that will tell you, for an input of graph isomorphism, is it part of a subclass of graph isomorphism which is NP-complete, and which has polynomial size.
This is useful information, thank you for sharing this theorem! I am still skeptical about the soundness of the verifier's challenge generating mechanism. Assuming P!=NP and the challenge is drawn uniformly from the full space, I am still not convinced that the prover does not have access to a backdoor which makes the challenge "easier" on average than the challenger realizes.
Even if challenge instances are superpolynomial in the worst case, empirically, we know from SAT solving competitions that a very small fraction of randomly sampled k-SAT instances are truly hard and most are in P. It is nontrivial to design a challenge whose average case is superpolynomial, and there are many open questions in the field of average-case complexity [1].
I would be very skeptical that the challenge generator is not somehow poisoned. Even if the prover did not collude with the protocol designer to poison it directly, if she can infer any information about the internal state of the verifier from the instances he proposes, she may be able to solve future challenges much more easily than would be possible by random chance.
